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

On 18.11.2020 0:20, Robinson, Paul wrote:
> This is a problem only if the .debug_str section *by itself* exceeds 4GB;
> are we anticipating that will happen IRL?  The section is just a string
> section, by itself it has no 32/64 format.
> 
> 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.

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

> > 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?

-cary

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.​