[PATCH] D76085: [DWARFLinker][dsymutil][NFC] add section index into address range.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 16 13:08:23 PDT 2020


dblaikie added a comment.

In D76085#1922838 <https://reviews.llvm.org/D76085#1922838>, @avl wrote:

> > But in the dsymutil scenario, debug info is not linked into the executable - so there would be no "non-optimized linked debug info sections". So I'm still confused here.
>
> Right. I had in mind the current behavior of LLD - it has a final stage where output generated and relocations resolved for all sections. Since we need linked addresses, we need to execute that stage.


I assume LLD has to figure out the final locations of things before it actually generates the output and resolves relocations (I mean, during generating the output it could then compute the final locations - but I think the final locations would be known and /then/ those sections would all be written to the output file).

>   As a result, the output would be generated for all sections(.text and .debug_info). 
>    
> 
> But that behavior could be changed. Debug info sections could be handled separately in two steps. lld could link non-debug sections first, then generate debug map, optimize debug info sections and finally link debug info sections.
> 
> Doing that way would avoid "NON-optimized debug info sections." generation.
> 
> Thus the only additional thing would be the generation of debug map.

If by "debug map" you mean a literal file, or file in memory - I think that could reasonably be avoided & changes to DWARFLinker to support an API-level description of the semantic contents of the debug map ("this address/section ended up at this final addresS" sort of info) would be quite reasonable.

>> Why does dsymutil need the linked binary? Isn't the debug map sufficient? & couldn't a similar mapping be produced part-way through linking inside lld?
> 
> debug map could be produced by lld. 
>  Though it would be an additional step. That step could be avoided if DWARFLinker becomes to work with sectioned addresses.
> 
>> The problem with only testing once that functionality surfaces into a binary is that we'll lose track of what all the new code is taht now needs testing - it's best to add testing as the behavior is implemented in the code.
> 
> I planned to add tests with code which would use sectioned addresses. 
>  I will add it now, If making DWARFLinker to work with sectioned addresses is OK in general.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76085





More information about the llvm-commits mailing list