[PATCH] D60470: [DWARF] Prefer larger DW_AT_low_pc when constructing aranges

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 15 21:55:02 PDT 2019


MaskRay added a comment.

> What happens if a program is linked from some objects with debug info and some objects without it?

This revision doesn't change the behavior. For the address ranges with no debug info, the results remain `??:0:0` (unknown).

> It sounds like this solution might not address that case (in this case, there might be no ambiguity - only one CU would have an address range covering the instruction address - but that instruction address would have no real debug info).

The motivation was to mitigate some issues of lld-linked modules => my approach is general and doesn't discuss anything specific as zero addresses, etc => this patch seems a bit useful for ld.bfd/gold linked modules (reasons at https://reviews.llvm.org/D60470#1462246)

> Should we use a different solution? Is GNU addr2line's solution robust, if slow? Or does it still fail in these sort of cases? &

I mentioned before (https://reviews.llvm.org/D60470#1460670) that addr2line's linear search can be faulty, as demonstrated by the following command:

  % addr2line -e res.out 0x2010f0
  /tmp/c/not_used.cpp:2

Linear search doesn't look more robust, but it is assuredly slow.

>   if it isn't complete, should we settle for fixing the linker & not try to partially support this in the symbolizer if it necessarily can't be complete in general?

This revision doesn't do any "involved" logic. It changes the rule about which range prevails when several ranges overlap. I even deleted a not useful "optimization"(trade-off) that (I think) cluttered the code.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60470





More information about the llvm-commits mailing list