From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17656 invoked by alias); 28 Sep 2008 20:46:02 -0000 Received: (qmail 17643 invoked by uid 22791); 28 Sep 2008 20:46:01 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 28 Sep 2008 20:45:26 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id m8SKjJpa000589 for ; Sun, 28 Sep 2008 21:45:20 +0100 Received: from localhost (ruffy.corp.google.com [172.18.118.116]) by wpaz5.hot.corp.google.com with ESMTP id m8SKjIJP021115 for ; Sun, 28 Sep 2008 13:45:18 -0700 Received: by localhost (Postfix, from userid 67641) id 2FD9E1C78DF; Sun, 28 Sep 2008 13:45:18 -0700 (PDT) To: gdb@sourceware.org Subject: 29 bits for dwarf2_per_cu_data.length ? Message-Id: <20080928204518.2FD9E1C78DF@localhost> Date: Sun, 28 Sep 2008 20:46:00 -0000 From: dje@google.com (Doug Evans) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00136.txt.bz2 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;