Re: 29 bits for dwarf2_per_cu_data.length ?

[Daniel Jacobowitz <drow@false.org>]

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