<div dir="ltr">Personally, I'm not aware of any fundamental reason why this can't be done.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 December 2017 at 16:48, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>>Hi,<br>
>><br>
>>My colleagues and I have actually been doing quite a bit of investigation<br>
>>in the past couple of weeks into what to do about debug data that refers to<br>
>>sections that are discarded due to --gc-sections etc. Currently, LLD treats<br>
>>the references as address zero, but at least on our platform, address zero<br>
>>is a valid address, so we were looking at alternatives. One of the ideas<br>
>>that I personally looked at was based on section E.3 of the DWARF4/5<br>
>>specifications, i.e. having a separate .debug_info section for each<br>
>>subprogram, each of which imports from a "main" .debug_info section<br>
>>containing shared information. I was able to prototype a change to LLVM<br>
>>that did this, without too much effort, given that I hadn't previously<br>
>>looked in that area of code before. I then had to modify LLD to recognise<br>
>>these new info sections as being dependent on the corresponding text<br>
>>section, which was a relatively simple change to make, thanks to the<br>
>>mechanism for dependent sections already being there. It didn't require<br>
>>inspecting the contents of the section, only the section name in my case<br>
>>(the sections in my experiment were named things like .debug_info._Z3foov).<br>
>>I also prototyped changes to llvm-dwarfdump to print the .debug_info for<br>
>>these multiple sections. Again, this was relatively simple, although I<br>
>>certainly didn't experiment beyond a very simply case. Similar<br>
>>investigations are being conducted for having multiple of other .debug_*<br>
>>sections.<br>
>><br>
>>We haven't yet decided whether this is an approach we'd like to push for,<br>
>>as there are some downsides (e.g. larger debug information) but my point is<br>
>>that I wouldn't be so certain that we won't need to handle multiple<br>
>>.debug_info sections correctly in the relatively near term, so I'd much<br>
>>rather option 2).<br>
>><br>
>>Regards,<br>
>><br>
>>James><br>
><br>
>Hi James, sorry, only thing I can say atm that I did not see your mail until David replied.<br>
>I suspect something was wrong with our mail server, I'll answer this<br>
>tommorrow.<br>
><br>
>George.<br>
<br>
</div></div>James, David, given the comments and my feelings, I think we should just support multiple .debug_info* sections.<br>
It anyways not something that will be harmfull given the current latest DWARF specification it seems.<br>
<br>
Sorry if I am missing something, but can we just do it ? (I can take this task I believe, FWIW).<br>
<span class="HOEnZb"><font color="#888888"><br>
George.<br>
</font></span></blockquote></div><br></div>