29 bits for dwarf2_per_cu_data.length ?

29 bits for dwarf2_per_cu_data.length ?

[Doug Evans]

For my DW_FORM_sig8 work I've found a need to distinguish DW_TAG_type_unit
CUs (or TUs) from normal DW_TAG_compile_unit CUs in dwarf2_per_cu_data.
The easy way is to make length 29 bits.

 struct dwarf2_per_cu_data
 {
-  /* The start offset and length of this compilation unit.  2**30-1
+  /* The start offset and length of this compilation unit.  2**29-1
      bytes should suffice to store the length of any compilation unit
      - if it doesn't, GDB will fall over anyway.  */
   unsigned long offset;
-  unsigned long length : 30;
+  unsigned long length : 29;
+
+  /* Non-zero if this CU is from .debug_types.
+     Otherwise it's from .debug_info.  */
+  unsigned long from_debug_types : 1;
 
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.

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?


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?


E.g.,

diff -u -p -d -u -r1.284 dwarf2read.c
--- dwarf2read.c	23 Sep 2008 17:36:51 -0000	1.284
+++ dwarf2read.c	28 Sep 2008 20:34:50 -0000
@@ -358,15 +358,13 @@ struct dwarf2_cu
 
 struct dwarf2_per_cu_data
 {
-  /* The start offset and length of this compilation unit.  2**30-1
-     bytes should suffice to store the length of any compilation unit
-     - if it doesn't, GDB will fall over anyway.  */
-  unsigned long offset;
-  unsigned long length : 30;
+  /* The start offset and length of this compilation unit.  */
+  unsigned int offset;
+  unsigned int length;
 
   /* Flag indicating this compilation unit will be read in before
      any of the current compilation units are processed.  */
-  unsigned long queued : 1;
+  unsigned int queued : 1;
 
   /* This flag will be set if we need to load absolutely all DIEs
      for this compilation unit, instead of just the ones we think
@@ -374,6 +372,10 @@ struct dwarf2_per_cu_data
      hash table and don't find it.  */
   unsigned int load_all_dies : 1;
 
+  /* Non-zero if this CU is from .debug_types.
+     Otherwise it's from .debug_info.  */
+  unsigned int from_debug_types : 1;
+
   /* Set iff currently read in.  */
   struct dwarf2_cu *cu;
 

Re: 29 bits for dwarf2_per_cu_data.length ?

[Daniel Jacobowitz]

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