[llvm-dev] [LLD] Support DWARF64, debug_info "sorting"

[Igor Kudrin via llvm-dev]

On 19.11.2020 03:21, Cary Coutant wrote:
>>> If the .debug_str section *by itself* exceeds 4GB, then yes any string
>>> with a 32-bit reference to it must be in the first 4GB.  Strings that
>>> have only 64-bit references to them can be sorted to the end of the
>>> section, if necessary.  I wouldn't think anyone guarantees or cares
>>> about the order of strings within a string section.
>>>
>>> But I think this would be the very last thing to care about, with regard
>>> to DWARF-64 concerns.
>>
>> I guess that the relative size of the ".debug_str" section may vary and depends on the source code, particular build environment, and lots of other circumstances. I've checked some fresh built samples and always see that the section is usually close in size to ".debug_info" and sometimes even bigger. So, this section must be ordered similarly as all other debugging info sections.
> 
> I agree with Paul, and I'm surprised by your findings. Can you post
> some actual numbers? In my experience, .debug_str is an order of
> magnitude smaller than .debug_info. Perhaps the binaries you're
> looking at haven't been string-merged?

As an example, here are the numbers for a fresh built CLANG in Debug 
mode on Ubuntu 20.04 using GCC 10.2:

$ readelf -SW clang-12 | grep debug | awk '{print $2, $6}' | column -t
.debug_aranges  00c240
.debug_info     34d1fd
.debug_abbrev   00841f
.debug_line     023093
.debug_str      53685f
.debug_ranges   00c300

As you can see, ".debug_str" is visibly bigger than ".debug_info". Of 
course, CLANG does not suffer from DWARF32 limits. This is just a 
relatively large project, which anyone can easily check by themselves.

-- 
Best Regards,
Igor Kudrin
C++ Developer, Access Softek, Inc.​