<div dir="ltr"><div dir="ltr">On Fri, Apr 21, 2023 at 12:44 PM John DelSignore <<a href="mailto:JDelSignore@perforce.com">JDelSignore@perforce.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Well, it took a long time to compile 5 CUs that contained your test code, and things were looking promising, but the link failed:<br>
</p>
<p><tt>rocm2 42 04/21 15:14 /build/jdelsign/fatty % make</tt><tt><br>
</tt><tt>g++ -g -c fatty4.cxx -o fatty4.o</tt><tt><br>
</tt><tt>g++ -g -c fatty5.cxx -o fatty5.o</tt><tt><br>
</tt><tt>g++ -g -o fatty fatty.o fatty2.o fatty3.o fatty4.o fatty5.o</tt><tt><br>
</tt><tt>fatty5.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 against `.debug_info'</tt><tt><br>
</tt><tt>collect2: error: ld returned 1 exit status</tt><tt><br>
</tt><tt>make: *** [Makefile:5: fatty] Error 1</tt><tt><br>
</tt><tt>rocm2 43 04/21 15:39 /build/jdelsign/fatty % </tt><tt><br>
</tt></p>
<p>I guess I'm now in favor of the proposal to get rid of .debug_aranges. :-)</p></div></blockquote><div>I guess, backing up - what's your goal/what're you trying to do with DWARF over 4GB?<br><br>You do have to use DWARF64 for a .debug_info section over 4GB - for any section-relative reference in that section, such as cross-CU references (sec_offset), or aranges or debug_names I think, etc. Because with DWARF32 the section references are 32bit, so can't exceed 4GB.<br><br>(also, with a different example, you'd get string data over 4GB, which you'd also need DWARF64 for, or in DWARFv5 (with some dispensations from DWARFv6) you could use DWARF64 for .debug_str_offsets (assuming all string references were strx forms) without using DWARF64 for everything else)<br><br>In Split DWARF if each contribution is <4GB you only need a 64 bit cu/tu_index and 64 bit str_offsets (& you could even do that selectively, only using DWARF64 str_offsets for contributions that need 64 bit offsets), since nothing else references across whole sections - which makes it much more scalable/easier to solve.<br><br>Also, another issue is that even if you have simple/small bits of DWARF32 (in some precompiled library, etc), if your total program exceeds 64 bit, you may not be able link the program because that DWARF32 might end up being put at the end of the section, and so the debug_aranges, for instance, needs to record the offset of the CU in 32 bits but can't. So there's various discussions about linkers being able to sort the DWARF32 contributions earlier/first before the DWARF64 contributions. Then you could still link DWARF32 precompiled libraries into huge programs that exceed the DWARF32 limits. I can go find some links to those threads/discussions if you need them, I think some happened in the LLVM open source community.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>Cheers, John D.<br>
</p>
<div>On 4/21/23 13:28, John DelSignore wrote:<br>
</div>
<blockquote type="cite">
<p>Thanks David, this is useful. I'll see what I can cobble together.</p>
<p>Cheers, John D.<br>
</p>
<div>On 4/20/23 21:58, David Blaikie wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Oh, and I guess you could always make something even more artificial by hand - if you compile some random code with -g to assembly, you could then just pad out a .debug_info contribution with lots of zeros (there are some assembly directives
for that, I think, but don't know assembly that well off hand) - would make it arbitrarily large without the need to tax the compiler creating novel/real DWARF, etc.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 20, 2023 at 6:54 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I /believe/ that Chromium (maybe specifically on ARM? not sure) may have hit/had problems with the 4GB limit - probably trivially if you build with clang but pass `-fstandalone-debug` which disables many type reduction/deduplication strategies.<br>
<br>
If you want something more standalone... this:<br>
<br>
<br>
<font face="monospace">#define MEMBERS(BASE) \<br>
int BASE##0 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##1 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##2 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##3 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##4 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##5 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##6 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##7 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##8 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \<br>
int BASE##9 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int);
<br>
template<int ... i><br>
struct t1 {<br>
MEMBERS(f0)<br>
MEMBERS(f1)<br>
MEMBERS(f2)<br>
MEMBERS(f3)<br>
MEMBERS(f4)<br>
MEMBERS(f5)<br>
MEMBERS(f6)<br>
MEMBERS(f7)<br>
MEMBERS(f8)<br>
MEMBERS(f9)<br>
};<br>
#define ITER(A, B) \<br>
template <int... i> \<br>
struct A { \<br>
B<i..., 0> v0; \<br>
B<i..., 1> v1; \<br>
B<i..., 2> v2; \<br>
B<i..., 3> v3; \<br>
B<i..., 4> v4; \<br>
B<i..., 5> v5; \<br>
B<i..., 6> v6; \<br>
B<i..., 7> v7; \<br>
B<i..., 8> v8; \<br>
B<i..., 9> v9; \<br>
};<br>
ITER(t2, t1);<br>
ITER(t3, t2);<br>
ITER(t4, t3);<br>
ITER(t5, t4);<br>
ITER(t6, t5);<br>
ITER(t7, t6);<br>
ITER(top, t7);<br>
int main() {<br>
t6<> v;<br>
}</font><br>
<br>
Doesn't quite hit 4GB, it's about 1.2GB in .debug_info (& takes 2.5 minutes to compile with clang) - 5 of these (could stamp them out by including this file into a few other source files & just changing the `main` function to some other name in each)<br>
<br>
This specifically doesn't push the .debug_str section as hard - it's about half the size of the .debug_info in this program.<br>
<br>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 20, 2023 at 7:08 AM John DelSignore via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is anyone aware of an open-source program or test program that when compiled and built on Linux x86_64, results in a .debug_info section that is greater than 4GB? I'm looking for a test program (realistic or not) that contains 32-bit DWARF CUs in a .debug_info
section that is about 5GB long, or longer.<br>
<br>
Thanks, John D.<br>
<br>
<br>
<br>
This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.<br>
<br>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<br>
<div align="center">
<table style="border-collapse:collapse;border:none" cellspacing="0" cellpadding="0" border="1">
<tbody>
<tr>
<td style="width:399.35pt;border:1.5pt double rgb(255,192,0);background:rgb(255,251,239);padding:0in 5.4pt" width="532" valign="top">
<p class="MsoNormal"><b><span style="color:rgb(191,143,0)">CAUTION:</span></b><span style="color:black"> This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.</span></p>
</td>
</tr>
</tbody>
</table>
</div>
</blockquote>
</blockquote>
<br>
<p><span style="font-size:8pt;color:rgb(166,166,166);font-style:italic">This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.</span></p>
<br>
</div>
</blockquote></div></div>