public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: David Taylor <dtaylor@emc.com>, gdb@sources.redhat.com
Subject: Re: macros, debug information, and parse_macro_definition
Date: Fri, 02 May 2003 19:21:00 -0000	[thread overview]
Message-ID: <vt2d6j1f8vw.fsf@zenia.red-bean.com> (raw)
In-Reply-To: <3EAE927E.4030005@redhat.com>


Andrew Cagney <ac131313@redhat.com> writes:

> > These encodings are simple enough that I wouldn't expect them to
> > change over time.
> > I would think it more likely that there would be a bug, either in
> > gcc's encoding of them or in gdb's processing of them.  And if the
> > code is duplicated, then both locations need to be modified to fix the
> > bug -- with the attendant risk that someone will modify one and forget
> > to modify the other.  Or will modify it, but accidentally make it
> > slightly different.
> 
> 
> > I don't know how people would feel about having STABS have a
> > description of the encoding combined with a caveat that the DWARF
> > 2.0.0 spec is authoritative.  I would certainly prefer that the STABS
> > document remain self contained.
> 
> I think this is a good strategy.  It's already a ``gcc extension'',
> and stealing an existing (known to be working) spec is always a good
> strategy :-)
> 
> Have you thought about link time information compression?  One of the
> complaints leveled at the macro stuff is the size of the resultant
> debug info.

Actually, I think that David's proposed representation will compress
really well, with no new linker work.  The linker's current behavior
will do everything that's needed.

Each entry in the .stab section is a fixed-size record; the textual
portion of the stab is represented as an offset into the .stabstr
section, which contains null-terminated strings.  The .stabstr section
is a SHT_STRTAB type section, which means that the linker will
automatically factor out duplicates.  So if two .stab entries have the
same text, they'll end up pointing to the same bytes in .stabstr in
the final executable.

In David's proposed representation, #including a file into many
different .o files will produce stabs entries with identical strings,
so they'll all get factored out nicely.

All this is completely independent of the BINCL/EINCL -> EXCL
compression the linker also does for STABS, to factor out duplicated
entries from the .stab section itself.

  parent reply	other threads:[~2003-05-02 19:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-22 16:40 David Taylor
2003-04-22 20:06 ` Kevin Buettner
2003-04-24  3:08 ` Jim Blandy
2003-04-24 15:12   ` David Taylor
2003-04-29 14:55     ` Andrew Cagney
2003-04-29 15:55       ` Daniel Berlin
2003-04-29 16:24         ` Keith Walker
2003-04-29 17:13           ` Daniel Berlin
2003-04-29 16:51       ` David Taylor
2003-05-02 19:21       ` Jim Blandy [this message]
2003-05-04 19:41         ` Andrew Cagney

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=vt2d6j1f8vw.fsf@zenia.red-bean.com \
    --to=jimb@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=dtaylor@emc.com \
    --cc=gdb@sources.redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).