Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH/ob] unify objfile obstacks(2/4)
Date: Sat, 07 Feb 2004 23:24:00 -0000	[thread overview]
Message-ID: <16421.29411.490179.382466@localhost.redhat.com> (raw)
In-Reply-To: <20040207023425.40A0D4B364@berman.michael-chastain.com>

Michael Elizabeth Chastain writes:
 > This comment in dbxread.c seems a bit wack now:
 > 
 > -  /* Read the string table and stash it away in the psymbol_obstack.  It is
 > +  /* Read the string table and stash it away in the objfile_obstack.  It is
 >       only needed as long as we need to expand psymbols into full symbols,
 >       so when we blow away the psymbol the string table goes away as well.
 > 
 > The psymbols are going to have the same lifetime as the symbols,
 > so talking about blowing away the psymbols seems weird.
 > 

Yes true, however we never did blow away the psymbols. The obstacks
always had the same lifetime. I.e. the comment was a bit weird to
start with. I'll clean that up though.

here:
Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.62
diff -u -p -r1.62 dbxread.c
--- dbxread.c   9 Jan 2004 16:26:17 -0000       1.62
+++ dbxread.c   7 Feb 2004 17:21:36 -0000
@@ -651,14 +651,13 @@ dbx_symfile_init (struct objfile *objfil
   DBX_SYMCOUNT (objfile) = bfd_get_symcount (sym_bfd);
   DBX_SYMTAB_OFFSET (objfile) = SYMBOL_TABLE_OFFSET;
  
-  /* Read the string table and stash it away in the psymbol_obstack.  It is
-     only needed as long as we need to expand psymbols into full symbols,
-     so when we blow away the psymbol the string table goes away as well.
+  /* Read the string table and stash it away in the objfile_obstack.
+     When we blow away the objfile the string table goes away as well.
      Note that gdb used to use the results of attempting to malloc the
      string table, based on the size it read, as a form of sanity check
[....]


all in now.


  reply	other threads:[~2004-02-07 23:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-07  2:34 Michael Elizabeth Chastain
2004-02-07 23:24 ` Elena Zannoni [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-06 21:30 Elena Zannoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16421.29411.490179.382466@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mec.gnu@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox