[PATCH] D95916: DebugInfo/Symbolize: Allow STT_NOTYPE/STT_GNU_IFUNC symbols for .symtab symbolization

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 8 03:10:18 PST 2021


jhenderson accepted this revision.
jhenderson added a comment.

In D95916#2547979 <https://reviews.llvm.org/D95916#2547979>, @MaskRay wrote:

> In D95916#2547955 <https://reviews.llvm.org/D95916#2547955>, @jhenderson wrote:
>
>> So I just thought about this - in the event we have two symbols at the same location with different types, e.g. STT_NOTYPE and STT_FUNC, I think it would make more sense to use the STT_FUNC symbols. I haven't checked GNU behaviour for this though. What does GNU do in that situation?
>
> addrline just picks the first symbol. I don't think this heuristic is useful. In the case where several aliases are defined at the same address, it is rare that they have different symbol types. (Even for symbol assignments, see lld D86263 <https://reviews.llvm.org/D86263>)
>
> An arguably slightly more useful heuristic is to prefer a non-local symbol to a local symbol, but personally I don't think it is worthy to implement, either. addrline does not implement this heuristic.

Having given it more thought, I agree that it probably isn't a useful heuristic - if two symbols are at the same location, it doesn't really matter which is picked, as the information provided should be plenty for the situation.

There is one other situation related to this, however: symbols with address 0. There could be both defined and undefined symbols at address 0. We probably want to restrict it to defined symbols only (I also wondered about absolute symbols, as they could be confused with the real function, but in some limited cases, absolute symbols could actually be the real function). Probably this should be a separate change though?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95916/new/

https://reviews.llvm.org/D95916



More information about the llvm-commits mailing list