Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section
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 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
> 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 \
> struct A { \
> B v0; \
> B v1; \
> B v2; \
> B v3; \
> B v4; \
> B v5; \
> B v6; \
> B v7; \
> B v8; \
> B 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> 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
>> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>>
>
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section
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
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 \
struct A { \
B v0; \
B v1; \
B v2; \
B v3; \
B v4; \
B v5; \
B v6; \
B v7; \
B v8; \
B 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> 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
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
[Dwarf-discuss] Seeking a test program with a >4GB .debug_info section
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 https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
