[Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

[John DelSignore]

Well, it took a long time to compile 5 CUs that contained your test code, and things were looking promising, but the link failed:

rocm2 42 04/21 15:14 /build/jdelsign/fatty % make
g++ -g -c fatty4.cxx -o fatty4.o
g++ -g -c fatty5.cxx -o fatty5.o
g++ -g -o fatty fatty.o fatty2.o fatty3.o fatty4.o fatty5.o
fatty5.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 against `.debug_info'
collect2: error: ld returned 1 exit status
make: *** [Makefile:5: fatty] Error 1
rocm2 43 04/21 15:39 /build/jdelsign/fatty %

I guess I'm now in favor of the proposal to get rid of .debug_aranges. :-)

Cheers, John D.

On 4/21/23 13:28, John DelSignore wrote:

Thanks David, this is useful. I'll see what I can cobble together.

Cheers, John D.

On 4/20/23 21:58, David Blaikie wrote:
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.

On Thu, Apr 20, 2023 at 6:54 PM David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>> wrote:
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.

If you want something more standalone... this:


#define MEMBERS(BASE) \
  int BASE##0 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##1 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##2 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##3 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##4 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##5 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##6 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##7 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##8 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int); \
  int BASE##9 (int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int);
template<int ... i>
struct t1 {
  MEMBERS(f0)
  MEMBERS(f1)
  MEMBERS(f2)
  MEMBERS(f3)
  MEMBERS(f4)
  MEMBERS(f5)
  MEMBERS(f6)
  MEMBERS(f7)
  MEMBERS(f8)
  MEMBERS(f9)
};
#define ITER(A, B)    \
  template <int... i> \
  struct A {         \
    B<i..., 0> v0;   \
    B<i..., 1> v1;   \
    B<i..., 2> v2;   \
    B<i..., 3> v3;   \
    B<i..., 4> v4;   \
    B<i..., 5> v5;   \
    B<i..., 6> v6;   \
    B<i..., 7> v7;   \
    B<i..., 8> v8;   \
    B<i..., 9> v9;   \
  };
ITER(t2, t1);
ITER(t3, t2);
ITER(t4, t3);
ITER(t5, t4);
ITER(t6, t5);
ITER(t7, t6);
ITER(top, t7);
int main() {
  t6<> v;
}

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)

This specifically doesn't push the .debug_str section as hard - it's about half the size of the .debug_info in this program.



On Thu, Apr 20, 2023 at 7:08 AM John DelSignore via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org<mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
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.

Thanks, John D.



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.

--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org<mailto:Dwarf-discuss@lists.dwarfstd.org>
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss<https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss>


CAUTION: 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.


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20230421/15f6d04b/attachment-0001.htm>