Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Michael Elizabeth Chastain]

> No.  It was a parenthetical comment.  It has nothing to do with any
> submitted patch.

Okay, I can go back in my cave then.  :)

> I do not know of any Linux distribution which changed the default to
> dwarf2.

The gdb doco recommends that people use dwarf-2 over stabs+
for c++ support and for macro support.  But I'm getting far afield
here.

mec> My personal estimate/opinion is that gdb HEAD can drop support for gcc 2
mec> some time around October 2005.
drow> "Making the test results worse" is a far cry from "dropping support".

That's true.  I'm just personally obsessed with gcc 2.

Michael C

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> That's OK, you're right on all counts anyway.  The bug does not render
> GCC 2.95 code undebuggable; it just interferes with prologue skipping
> and setting breakpoints on the first line of functions, in some cases. 
> Both of which are testsuite is heavily biased towards.

Ummm, just to be clear, you're not about to make the test results worse
with gcc 2.95.3, are you?

BTW, gcc 2.95.3 on native i686-pc-linux-gnu does indeed default to
stabs+, but who knows what the default is on various distros.  And here
is a quick list of some gcc-2 based distros: freebsd 4, netbsd 1.6,
openbsd 3.4, debian 3.0, vine 2.6, gnoppix 0.6, lindows 4.5,
lycoris build3.

My personal estimate/opinion is that gdb HEAD can drop support for gcc 2
some time around October 2005.

Michael C

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Daniel Jacobowitz]

On Mon, Apr 19, 2004 at 02:26:21PM -0400, Michael Chastain wrote:
> Daniel Jacobowitz writes:
> > That's OK, you're right on all counts anyway.  The bug does not render
> > GCC 2.95 code undebuggable; it just interferes with prologue skipping
> > and setting breakpoints on the first line of functions, in some cases. 
> > Both of which are testsuite is heavily biased towards.
> 
> Ummm, just to be clear, you're not about to make the test results worse
> with gcc 2.95.3, are you?

No.  It was a parenthetical comment.  It has nothing to do with any
submitted patch.

> BTW, gcc 2.95.3 on native i686-pc-linux-gnu does indeed default to
> stabs+, but who knows what the default is on various distros.  And here
> is a quick list of some gcc-2 based distros: freebsd 4, netbsd 1.6,
> openbsd 3.4, debian 3.0, vine 2.6, gnoppix 0.6, lindows 4.5,
> lycoris build3.

I do not know of any Linux distribution which changed the default to
dwarf2.

> My personal estimate/opinion is that gdb HEAD can drop support for gcc 2
> some time around October 2005.

"Making the test results worse" is a far cry from "dropping support".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Daniel Jacobowitz]

dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
previous patches, there are only two things left on it: the linked list we
use to fudge GCC 2.95 line number tables (some day soon I think this hack
should go away; it was primarily for the benefit of the testsuite, and was
fixed at least as of GCC 3.1), and the block structures created in
read_attribute_value.

Both of these are clearly associated with a particular compilation unit.
If we put them on the comp_unit_obstack, then we don't have any need for
the global obstack any more.

Since my following patches change the lifetimes of individual CUs, I felt
this was a worthwhile cleanup.  OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-04-18  Daniel Jacobowitz  <drow@mvista.com>

	* dwarf2read.c (dwarf2_tmp_obstack, dwarf2_free_tmp_obstack):
	Delete.
	(dwarf_alloc_block): Take a CU argument.  Use the comp_unit_obstack.
	(read_attribute_value): Update calls to dwarf_alloc_block.
	(dwarf2_build_psymtabs_hard): Don't initialize or clean up
	dwarf2_tmp_obstack.
	(psymtab_to_symtab_1): Likewise.  Clean up using
	free_stack_comp_unit.
	(add_to_cu_func_list): Use the comp_unit_obstack.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.146
diff -u -p -r1.146 dwarf2read.c
--- dwarf2read.c	16 Apr 2004 16:12:52 -0000	1.146
+++ dwarf2read.c	19 Apr 2004 02:14:15 -0000
@@ -494,9 +494,6 @@ struct dwarf_block
 
 static struct die_info *die_ref_table[REF_HASH_SIZE];
 
-/* Obstack for allocating temporary storage used during symbol reading.  */
-static struct obstack dwarf2_tmp_obstack;
-
 /* Allocate fields for structs, unions and enums in this size.  */
 #ifndef DW_FIELD_ALLOC_CHUNK
 #define DW_FIELD_ALLOC_CHUNK 4
@@ -910,9 +907,7 @@ static struct type *dwarf2_fundamental_t
 
 /* memory allocation interface */
 
-static void dwarf2_free_tmp_obstack (void *);
-
-static struct dwarf_block *dwarf_alloc_block (void);
+static struct dwarf_block *dwarf_alloc_block (struct dwarf2_cu *);
 
 static struct abbrev_info *dwarf_alloc_abbrev (struct dwarf2_cu *);
 
@@ -1209,42 +1204,10 @@ dwarf2_build_psymtabs_hard (struct objfi
   char *beg_of_comp_unit;
   struct partial_die_info comp_unit_die;
   struct partial_symtab *pst;
-  struct cleanup *back_to;
   CORE_ADDR lowpc, highpc, baseaddr;
 
   info_ptr = dwarf2_per_objfile->info_buffer;
 
-  /* We use dwarf2_tmp_obstack for objects that don't need to survive
-     the partial symbol scan, like attribute values.
-
-     We could reduce our peak memory consumption during partial symbol
-     table construction by freeing stuff from this obstack more often
-     --- say, after processing each compilation unit, or each die ---
-     but it turns out that this saves almost nothing.  For an
-     executable with 11Mb of Dwarf 2 data, I found about 64k allocated
-     on dwarf2_tmp_obstack.  Some investigation showed:
-
-     1) 69% of the attributes used forms DW_FORM_addr, DW_FORM_data*,
-        DW_FORM_flag, DW_FORM_[su]data, and DW_FORM_ref*.  These are
-        all fixed-length values not requiring dynamic allocation.
-
-     2) 30% of the attributes used the form DW_FORM_string.  For
-        DW_FORM_string, read_attribute simply hands back a pointer to
-        the null-terminated string in info_buffer, so no dynamic
-        allocation is needed there either.
-
-     3) The remaining 1% of the attributes all used DW_FORM_block1.
-        75% of those were DW_AT_frame_base location lists for
-        functions; the rest were DW_AT_location attributes, probably
-        for the global variables.
-
-     Anyway, what this all means is that the memory the dwarf2
-     reader uses as temporary space reading partial symbols is about
-     0.5% as much as we use for dwarf_*_buffer.  That's noise.  */
-
-  obstack_init (&dwarf2_tmp_obstack);
-  back_to = make_cleanup (dwarf2_free_tmp_obstack, NULL);
-
   /* Since the objects we're extracting from .debug_info vary in
      length, only the individual functions to extract them (like
      read_comp_unit_head and load_partial_die) can really know whether
@@ -1360,7 +1323,6 @@ dwarf2_build_psymtabs_hard (struct objfi
 
       do_cleanups (back_to_inner);
     }
-  do_cleanups (back_to);
 }
 
 /* Process all loaded DIEs for compilation unit CU, starting at FIRST_DIE.
@@ -2053,8 +2015,8 @@ psymtab_to_symtab_1 (struct partial_symt
   /* We're in the global namespace.  */
   processing_current_prefix = "";
 
-  obstack_init (&dwarf2_tmp_obstack);
-  back_to = make_cleanup (dwarf2_free_tmp_obstack, NULL);
+  obstack_init (&cu.comp_unit_obstack);
+  back_to = make_cleanup (free_stack_comp_unit, &cu);
 
   buildsym_init ();
   make_cleanup (really_free_pendings, NULL);
@@ -2354,7 +2316,7 @@ add_to_cu_func_list (const char *name, C
   struct function_range *thisfn;
 
   thisfn = (struct function_range *)
-    obstack_alloc (&dwarf2_tmp_obstack, sizeof (struct function_range));
+    obstack_alloc (&cu->comp_unit_obstack, sizeof (struct function_range));
   thisfn->name = name;
   thisfn->lowpc = lowpc;
   thisfn->highpc = highpc;
@@ -5037,7 +4999,7 @@ read_attribute_value (struct attribute *
       info_ptr += bytes_read;
       break;
     case DW_FORM_block2:
-      blk = dwarf_alloc_block ();
+      blk = dwarf_alloc_block (cu);
       blk->size = read_2_bytes (abfd, info_ptr);
       info_ptr += 2;
       blk->data = read_n_bytes (abfd, info_ptr, blk->size);
@@ -5045,7 +5007,7 @@ read_attribute_value (struct attribute *
       DW_BLOCK (attr) = blk;
       break;
     case DW_FORM_block4:
-      blk = dwarf_alloc_block ();
+      blk = dwarf_alloc_block (cu);
       blk->size = read_4_bytes (abfd, info_ptr);
       info_ptr += 4;
       blk->data = read_n_bytes (abfd, info_ptr, blk->size);
@@ -5074,7 +5036,7 @@ read_attribute_value (struct attribute *
       info_ptr += bytes_read;
       break;
     case DW_FORM_block:
-      blk = dwarf_alloc_block ();
+      blk = dwarf_alloc_block (cu);
       blk->size = read_unsigned_leb128 (abfd, info_ptr, &bytes_read);
       info_ptr += bytes_read;
       blk->data = read_n_bytes (abfd, info_ptr, blk->size);
@@ -5082,7 +5044,7 @@ read_attribute_value (struct attribute *
       DW_BLOCK (attr) = blk;
       break;
     case DW_FORM_block1:
-      blk = dwarf_alloc_block ();
+      blk = dwarf_alloc_block (cu);
       blk->size = read_1_byte (abfd, info_ptr);
       info_ptr += 1;
       blk->data = read_n_bytes (abfd, info_ptr, blk->size);
@@ -8098,19 +8060,13 @@ decode_locdesc (struct dwarf_block *blk,
 
 /* memory allocation interface */
 
-static void
-dwarf2_free_tmp_obstack (void *ignore)
-{
-  obstack_free (&dwarf2_tmp_obstack, NULL);
-}
-
 static struct dwarf_block *
-dwarf_alloc_block (void)
+dwarf_alloc_block (struct dwarf2_cu *cu)
 {
   struct dwarf_block *blk;
 
   blk = (struct dwarf_block *)
-    obstack_alloc (&dwarf2_tmp_obstack, sizeof (struct dwarf_block));
+    obstack_alloc (&cu->comp_unit_obstack, sizeof (struct dwarf_block));
   return (blk);
 }
 

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Eli Zaretskii]

> Date: Sun, 18 Apr 2004 23:17:44 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
> previous patches, there are only two things left on it: the linked list we
> use to fudge GCC 2.95 line number tables (some day soon I think this hack
> should go away; it was primarily for the benefit of the testsuite, and was
> fixed at least as of GCC 3.1)

FWIW, I don't think it's time to dump support for GCC 2.95: it is
still in wide use as the system compiler on many GNU platforms.

That doesn't mean I'm opposed to the proposed patch, though.

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Jim Blandy]

Eli Zaretskii <eliz@elta.co.il> writes:

> > Date: Sun, 18 Apr 2004 23:17:44 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
> > previous patches, there are only two things left on it: the linked list we
> > use to fudge GCC 2.95 line number tables (some day soon I think this hack
> > should go away; it was primarily for the benefit of the testsuite, and was
> > fixed at least as of GCC 3.1)
> 
> FWIW, I don't think it's time to dump support for GCC 2.95: it is
> still in wide use as the system compiler on many GNU platforms.

I think you are right about the prevalence of GCC 2.95.  Michael
Chastain has made the same sorts of comments.

But dropping the kludge in question is not the same as dropping GCC
2.95 support.  The kludge is a fix for a specific GCC 2.95 bug, and if
I remember right, GDB had been in widespread use with that compiler
for several releases before the bug got fixed.  I think GCC 2.95
defaulted to STABS on the i386 anyway.  (I apologize for being too
lazy to search the archives to verify all this.)

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Daniel Jacobowitz]

On Mon, Apr 19, 2004 at 01:58:40AM -0500, Jim Blandy wrote:
> Eli Zaretskii <eliz@elta.co.il> writes:
> 
> > > Date: Sun, 18 Apr 2004 23:17:44 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
> > > previous patches, there are only two things left on it: the linked list we
> > > use to fudge GCC 2.95 line number tables (some day soon I think this hack
> > > should go away; it was primarily for the benefit of the testsuite, and was
> > > fixed at least as of GCC 3.1)
> > 
> > FWIW, I don't think it's time to dump support for GCC 2.95: it is
> > still in wide use as the system compiler on many GNU platforms.
> 
> I think you are right about the prevalence of GCC 2.95.  Michael
> Chastain has made the same sorts of comments.
> 
> But dropping the kludge in question is not the same as dropping GCC
> 2.95 support.  The kludge is a fix for a specific GCC 2.95 bug, and if
> I remember right, GDB had been in widespread use with that compiler
> for several releases before the bug got fixed.  I think GCC 2.95
> defaulted to STABS on the i386 anyway.  (I apologize for being too
> lazy to search the archives to verify all this.)

That's OK, you're right on all counts anyway.  The bug does not render
GCC 2.95 code undebuggable; it just interferes with prologue skipping
and setting breakpoints on the first line of functions, in some cases. 
Both of which are testsuite is heavily biased towards.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
> previous patches, there are only two things left on it: the linked list we
> use to fudge GCC 2.95 line number tables (some day soon I think this hack
> should go away; it was primarily for the benefit of the testsuite, and was
> fixed at least as of GCC 3.1), and the block structures created in
> read_attribute_value.
> 
> Both of these are clearly associated with a particular compilation unit.
> If we put them on the comp_unit_obstack, then we don't have any need for
> the global obstack any more.
> 
> Since my following patches change the lifetimes of individual CUs, I felt
> this was a worthwhile cleanup.  OK?

You need to fix up the comments above free_stack_comp_unit; it's no
longer "only used during partial symbol processing".

I'd like free_stack_comp_unit renamed to free_comp_unit_obstack, so
that when I search for comp_unit_obstack, I'll also run into the calls
to make_cleanup that will free it.

Otherwise, looks good.

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Daniel Jacobowitz]

On Mon, Apr 19, 2004 at 01:32:38AM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
> > previous patches, there are only two things left on it: the linked list we
> > use to fudge GCC 2.95 line number tables (some day soon I think this hack
> > should go away; it was primarily for the benefit of the testsuite, and was
> > fixed at least as of GCC 3.1), and the block structures created in
> > read_attribute_value.
> > 
> > Both of these are clearly associated with a particular compilation unit.
> > If we put them on the comp_unit_obstack, then we don't have any need for
> > the global obstack any more.
> > 
> > Since my following patches change the lifetimes of individual CUs, I felt
> > this was a worthwhile cleanup.  OK?
> 
> You need to fix up the comments above free_stack_comp_unit; it's no
> longer "only used during partial symbol processing".

Will do.

> I'd like free_stack_comp_unit renamed to free_comp_unit_obstack, so
> that when I search for comp_unit_obstack, I'll also run into the calls
> to make_cleanup that will free it.
> 
> Otherwise, looks good.

Mind if I don't do this one?  Right now, we have:

/* This cleanup function is passed the address of a dwarf2_cu on the stack
   when we're finished with it.  We can't free the pointer itself, but
   release any associated storage.

But on the intercu branch, it says:

/* This cleanup function is passed the address of a dwarf2_cu on the stack
   when we're finished with it.  We can't free the pointer itself, but be
   sure to unlink it from the cache.  Also release any associated storage
   and perform cache maintenance.

The most important thing the function does is remove a pointer from the
objfile's compilation unit cache to the stack frame of the function
that's ending.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:

> On Mon, Apr 19, 2004 at 01:32:38AM -0500, Jim Blandy wrote:
> > 
> > Daniel Jacobowitz <drow@false.org> writes:
> > > dwarf2_tmp_obstack serves as a general purpose dumping ground.  After my
> > > previous patches, there are only two things left on it: the linked list we
> > > use to fudge GCC 2.95 line number tables (some day soon I think this hack
> > > should go away; it was primarily for the benefit of the testsuite, and was
> > > fixed at least as of GCC 3.1), and the block structures created in
> > > read_attribute_value.
> > > 
> > > Both of these are clearly associated with a particular compilation unit.
> > > If we put them on the comp_unit_obstack, then we don't have any need for
> > > the global obstack any more.
> > > 
> > > Since my following patches change the lifetimes of individual CUs, I felt
> > > this was a worthwhile cleanup.  OK?
> > 
> > You need to fix up the comments above free_stack_comp_unit; it's no
> > longer "only used during partial symbol processing".
> 
> Will do.
> 
> > I'd like free_stack_comp_unit renamed to free_comp_unit_obstack, so
> > that when I search for comp_unit_obstack, I'll also run into the calls
> > to make_cleanup that will free it.
> > 
> > Otherwise, looks good.
> 
> Mind if I don't do this one?  Right now, we have:
> 
> /* This cleanup function is passed the address of a dwarf2_cu on the stack
>    when we're finished with it.  We can't free the pointer itself, but
>    release any associated storage.
> 
> But on the intercu branch, it says:
> 
> /* This cleanup function is passed the address of a dwarf2_cu on the stack
>    when we're finished with it.  We can't free the pointer itself, but be
>    sure to unlink it from the cache.  Also release any associated storage
>    and perform cache maintenance.
> 
> The most important thing the function does is remove a pointer from the
> objfile's compilation unit cache to the stack frame of the function
> that's ending.

So, it's supposed to do more than just free that obstack --- it does
whatever cleanups are necessary; for the more complicated structures
used in the full intercu code, that's more than freeing an obstack.
Okay, I'll go along with that.

Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack

[Daniel Jacobowitz]

On Mon, Apr 19, 2004 at 01:11:48PM -0500, Jim Blandy wrote:
> So, it's supposed to do more than just free that obstack --- it does
> whatever cleanups are necessary; for the more complicated structures
> used in the full intercu code, that's more than freeing an obstack.
> Okay, I'll go along with that.

Right.  I've checked this in.  Another patch tomorrow...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer