This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: 29 bits for dwarf2_per_cu_data.length ?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Doug Evans <dje at google dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 29 Sep 2008 09:38:35 -0400
- Subject: Re: 29 bits for dwarf2_per_cu_data.length ?
- References: <20080928204518.2FD9E1C78DF@localhost>
On Sun, Sep 28, 2008 at 01:45:18PM -0700, Doug Evans wrote:
> That shrinks the maximum size of a CU from 1G to 512M.
> I'm guessing it's a non-starter (although 512M for one CU is still a lot),
> but before I try something else I thought I'd check.
I think 29 bits is still fine. A 512MB CU is going to produce
probably upwards of 2GB in internalized debugging information. The
first time someone comes up to us with a file that big, we'll want to
accomodate it; but for now, I'd be surprised to see it. 512MB
.debug_info, sure - that is easily within the reach of modern
applications.
> OTOH, on 64 bit targets there is 32 bits of alignment padding
> in dwarf2_per_cu_data. DIE's are a lot smaller these days, and there
> are a whole lot more of them than CUs.
> Can I spend a teensy bit of that gain and make dwarf2_per_cu_data 32 bits
> bigger for 32-bit targets?
That'd be fine with me too.
> A related question: dwarf2_per_cu_data.offset is 64 bits on 64-bit
> targets (unsigned long) and yet most other places only use 32 bits
> (unsigned int). E.g., partial_die_info.offset.
> Can I change everything to use an unsigned it?
Yes - though maybe a typedef? dwarf_off_t?
--
Daniel Jacobowitz
CodeSourcery