[PATCH] D40950: [ELF] - Fail when multiple .debug_* sections are used in a single object.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 11 08:04:21 PST 2017


>Hi,
>
>My colleagues and I have actually been doing quite a bit of investigation
>in the past couple of weeks into what to do about debug data that refers to
>sections that are discarded due to --gc-sections etc. Currently, LLD treats
>the references as address zero, but at least on our platform, address zero
>is a valid address, so we were looking at alternatives. One of the ideas
>that I personally looked at was based on section E.3 of the DWARF4/5
>specifications, i.e. having a separate .debug_info section for each
>subprogram, each of which imports from a "main" .debug_info section
>containing shared information. I was able to prototype a change to LLVM
>that did this, without too much effort, given that I hadn't previously
>looked in that area of code before. I then had to modify LLD to recognise
>these new info sections as being dependent on the corresponding text
>section, which was a relatively simple change to make, thanks to the
>mechanism for dependent sections already being there. It didn't require
>inspecting the contents of the section, only the section name in my case
>(the sections in my experiment were named things like .debug_info._Z3foov).
>I also prototyped changes to llvm-dwarfdump to print the .debug_info for
>these multiple sections. Again, this was relatively simple, although I
>certainly didn't experiment beyond a very simply case. Similar
>investigations are being conducted for having multiple of other .debug_*
>sections.
>
>We haven't yet decided whether this is an approach we'd like to push for,
>as there are some downsides (e.g. larger debug information) but my point is
>that I wouldn't be so certain that we won't need to handle multiple
>.debug_info sections correctly in the relatively near term, so I'd much
>rather option 2).
>
>Regards,
>
>James

Hi James, sorry, only thing I can say atm that I did not see your mail until David replied. 
I suspect something was wrong with our mail server, I'll answer this
tommorrow.

George.


More information about the llvm-commits mailing list