labath added a comment.

Just to clarify: I was responding to the question about the ELF file usage, not 
questioning the overall approach. Given that MachO has a special code for dsym 
files, I think it makes sense to use it.

In D141330#4043807 <https://reviews.llvm.org/D141330#4043807>, @jasonmolenda 
wrote:

>   By scanning the table, a debugger can quickly decide which compilation unit 
> to look in to find the debugging information for an object that has a given 
> address.
>   
>   If the range of addresses covered by the text and/or data of a compilation 
> unit is not contiguous, then there may be multiple address range descriptors 
> for that compilation unit.
>
> (I dislike it when the standard says "there MAY be multiple address range 
> descriptors" -- does this mean if I have a noncontiguous CUs A and B 
> interleaved in the final binary, the debug_aranges can overlap?)

I see what you mean, but I wouldn't really read it that way, and I hope nobody 
produces files like that.

> There's no guarantee for (1) if a debug_aranges table is present, but maybe 
> we can simply assume that any producer producing debug_aranges has done so 
> comprehensively.  I couldn't imagine why it wouldn't be that way.

We can't do that because, as I alluded to in the other comment, the aranges 
section can be produced by the compiler, and there's no guarantee that all CUs 
will be built with the same flags (so some may be missing that section). In the 
elf world a linker will just concatenate those sections without trying to fill 
in the blanks.

A normal binary includes some code from the system runtime (which is built by 
the OS vendor not the user). Typically, that code will not have debug info, but 
sometimes it does, and in that case it's pretty much guaranteed that it will be 
built using different compiler/flags than the user code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141330

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to