[Lldb-commits] [PATCH] Strip ELF symbol versions from symbol names

[Greg Clayton]

> On Feb 26, 2015, at 2:54 AM, Pavel Labath <labath at google.com> wrote:
> 
> The situation is not as simple as considering "memcpy@@GLIBC_2.14" as a mangled version and "memcpy" as unmangled. It is more like the "@@VERSION" suffix gets added to whatever name is produced by the compiler, when you want to do ELF symbol versioning. Which means the string before the "@@" could be mangled already.  Looking through the debug symbols of libstdc++ I have found a couple of symbols like "_ZSt10adopt_lock@@GLIBCXX_3.4.11". Here it would be natural to say _ZSt10adopt_lock is the mangled version and "std::adopt_lock" the unmangled. The "@@GLIBCXX_3.4.11" is a version tag used by the elf linker/loader, but is not a part of the symbol name as far as the compiler is concerned -- it is added by deep assembler/linker magic.
> 
> I agree that it would be nice to preserve the full symbol name, but I think this would require a new field in the Symbol class to do it properly. I can do that if you think it is the best.

Interesting. So really you want to make a symbol table that will work for displaying stuff to the user and also when doing lookups for the expression parser. I don't want to add anything to the Symbol class as it is one of the largest memory producing classes in LLDB. Anything we add will increase memory dramatically, so I would prefer not to add anything.

> 
>> At the risk of being too picky, we might also want to support calling the correct version of memcpy based on the version of glibc that you are using. It's not particularly important in 
> 
>> this case (glibc 2.15 is my personal minspec. But there may be other instances.
> 
> 
> With this patch and debug-glibc, "expr memcpy(...)" will call whatever is the latest version of memcpy in the library.
> Without this patch and with debug-glibc, "expr memcpy(...)" will return an error.
> 
> Without debug symbols in glibc we actually end up with two definitions of memcpy in our symbol table (in the .dynsym table the symbol version is not stored as a @ suffix but in a separate section, which we ignore) and "expr" will call a random one. (regardless of whether this patch is applied or not)
> 
> This could be a problem if a user program links with an old version of the symbol. Then he would see "memcpy(...)" in his source code, but if he would try to debug it by issuing an "expr memcpy" command, it would end up taking a different codepath. However, detecting this will not be easy, since you can in theory have different parts of your programs linking to different symbol versions. However, this shouldn't be much of a problem since normally when you compile your program afresh, it will pick the latest version available.
> 
> I will hold with the submitting until we can find an acceptable solution.
> 
> PS: I know that GLIBC_2.14 sounds old, but this just means that the function has not changed significantly since 2.14. The version of glibc I am looking at is 2.19.
> 
> 
> http://reviews.llvm.org/D7884
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
>