[lldb-dev] Extraneous SYMTAB entries, what am I missing?

[Greg Clayton]

Yes, there are many functions that can be "aliased" to one another using linker flags, assembly code can create multiple visible labels at the same address.

When in doubt, dump the symbol table with "nm" and see what it says about these symbols. It will often include extra text to describe what the symbol is.

Greg

On Sep 4, 2013, at 11:56 AM, Sean Hermany <sean at crittercism.com> wrote:

> (If anyone knows of a better list/spot to ask, please feel free to refer me, I don't want to add unnecessary noise here.)
> 
> I have a custom written tool that parses the symbol table entries in dSYMs for when DWARF data is unavailable for a given symbol (doing symbolication on linux, but, besides the point.)
> 
> I'm finding certain cases where a there will be multiple nlist entries in a row with the same nvalue (in fact, all of the fields are the same), except for the index into the string table. It seems that the first entry points to the correct symbol name in the string table, then the following entry (or entries) point to what look like bogus names, i.e. things like "m_72b", "m_72c", "m_72e", etc.
> 
> When I symbolicate using atos, it spits out the first (correct) symbol name. My tool gets this wrong, because the subsequent entries over-write my search data structure entry for that particular n_value.
> 
> I checked this against the lldb symbolication framework exposes via the python interface, and it produces the same output as my tool.
> 
> This leads me to think that atos is coded to ignore all but the first entry it finds for a given address, whereas whatever symbolication engine lldb is exposing is following the same behavior my tool is.
> 
> Anyone have any idea what would be producing those extra nlist entries, or what they are?
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev