We always resolve duplicate symbols to the "closest" one to the current frame. So if there are two versions of putchar and one is in the library containing the current frame, we should find that one. If we aren't getting that right, that's a bug. So the correct symbol should get called in cases where it makes sense. But if you are in main, and you have two libraries with rewritten putchar's it isn't clear which one we should call, and I think it isn't all that unexpected that we would just raise an error. If the duplicate symbols are both exported, but there's other linker magic to pick one over the other in main, then we'd have to know about that to get the right symbol. But I think that's orthogonal to this discussion.
Jim > On Jul 13, 2016, at 2:55 PM, Stephane Sezer <s...@cd80.net> wrote: > > sas added a comment. > > In http://reviews.llvm.org/D22294#483264, @clayborg wrote: > >> Note that during function lookup, we can find **both** "putchar" and >> "__my_putchar" in the debug info, so you will be able to call both. > > > Correct, unless as you pointed out both symbols are in libraries, and not in > the main executable. > > Our experience using this feature of clang has been that both symbols being > in libraries is the rule rather than the exception. > > See r221548 in llvm which introduces the symbol rewriter pass. This > functionality is used for things like interposing of libraries, etc, or > experiments where two versions of the same library are running alongside each > other. This means that in the general use case, you have both the > non-rewritten as well as the rewritten library loaded in the process. > > FWIW, the current version of lldb is already able to call `_my_putchar`, > given that this is the name present in the Mach-O symbol table. > > > http://reviews.llvm.org/D22294 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
