<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Debug info section is still only 3.4 MB. <br>
Just to add another data point. Internally for statically linked library where debug info section varies from 3.3GB to 4GB, the debug_strng section varies from 1.8GB to 2.2GB.<br>
<br>
I guess fundamental question is as debug_info grows from MB to GB, how well does debug_str scales.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
Alex</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Igor Kudrin <ikudrin@accesssoftek.com><br>
<b>Sent:</b> Wednesday, November 18, 2020 9:59 PM<br>
<b>To:</b> Cary Coutant <ccoutant@gmail.com><br>
<b>Cc:</b> Robinson, Paul <paul.robinson@sony.com>; Fāng-ruì Sòng <maskray@google.com>; Alexander Yermolovich <ayermolo@fb.com>; llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting"</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 19.11.2020 03:21, Cary Coutant wrote:<br>
>>> If the .debug_str section *by itself* exceeds 4GB, then yes any string<br>
>>> with a 32-bit reference to it must be in the first 4GB. Strings that<br>
>>> have only 64-bit references to them can be sorted to the end of the<br>
>>> section, if necessary. I wouldn't think anyone guarantees or cares<br>
>>> about the order of strings within a string section.<br>
>>><br>
>>> But I think this would be the very last thing to care about, with regard<br>
>>> to DWARF-64 concerns.<br>
>><br>
>> 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.<br>
> <br>
> I agree with Paul, and I'm surprised by your findings. Can you post<br>
> some actual numbers? In my experience, .debug_str is an order of<br>
> magnitude smaller than .debug_info. Perhaps the binaries you're<br>
> looking at haven't been string-merged?<br>
<br>
As an example, here are the numbers for a fresh built CLANG in Debug <br>
mode on Ubuntu 20.04 using GCC 10.2:<br>
<br>
$ readelf -SW clang-12 | grep debug | awk '{print $2, $6}' | column -t<br>
.debug_aranges 00c240<br>
.debug_info 34d1fd<br>
.debug_abbrev 00841f<br>
.debug_line 023093<br>
.debug_str 53685f<br>
.debug_ranges 00c300<br>
<br>
As you can see, ".debug_str" is visibly bigger than ".debug_info". Of <br>
course, CLANG does not suffer from DWARF32 limits. This is just a <br>
relatively large project, which anyone can easily check by themselves.<br>
<br>
-- <br>
Best Regards,<br>
Igor Kudrin<br>
C++ Developer, Access Softek, Inc.<br>
</div>
</span></font></div>
</body>
</html>