From: Elena Zannoni <ezannoni@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Jim Blandy <jimb@redhat.com>, Elena Zannoni <ezannoni@redhat.com>,
gdb-patches@sources.redhat.com
Subject: Re: RFC: support debug info in separate files
Date: Tue, 10 Dec 2002 09:14:00 -0000 [thread overview]
Message-ID: <15862.3912.243064.423628@localhost.redhat.com> (raw)
In-Reply-To: <3DF6107D.7080708@redhat.com>
Andrew Cagney writes:
> Hmm, to wear fernando's hat :-) Is there a new test that demonstrates
> this feature?
You need the special strip program. One could think of avoiding
running strip by storing the blah.debug files in the gdb.base source
directory, but then the executable built at the time you run the tests
wouldn't be stripped as gdb expects it. One other way would be to
maybe store the strip program somewhere in the gdb source, but I don't
think this elfutils/strip is FSF.
I know that Jim was able to run the testsuite but I think he relied on
having the proper strip installed on the system.
Elena
>
> > Some random comments...
> >
> > This works only for Elf. Will this interfere when other file formats
> > are processed? (I haven't tried with a, say, coff file, which is
> > impossible of course because this is elfutils based).
> >
> > > * utils.c (calc_crc32): New function.
> > > * defs.h (calc_crc32): New declaration.
> >
> > Now we have 4 identical crc32's functions in gdb. Any chance to
> > delete a few?
> >
> > For the debug file name suggest looking at HAVE_DOS_BASED_FILE_SYSTEM
> > in libiberty, and its uses in gdb/source.c.
> >
> > [...]
> >
> > > + strcat (debugfile, ".debug/");
> > [...]
> >
> > > + strcat (debugfile, "/");
> >
> > [...]
> > > + strcat (debugfile, "/");
> >
> > Should these be DIR_SEPARATOR instead? I guess DJGPP doesn't care though.
> >
> > In this message,
> > http://sources.redhat.com/ml/gdb/2002-09/msg00312.html I pointed out a
> > few things that could be done to improve this patch. For instance,
> > instead of adding a completely new objfile that would be only for the
> > debug info, add the debug info to the existing objfiles. I haven't
> > had a chance to see if you changed the patch to do something different
> > or not. It also seemed at that stage that we were gaining an extra
> > copy of the minimal symbols, and this can bloat gdb even more. Was
> > this changed?
> >
> > Other comments I pointed out in that message have been addressed by
> > Alex already.
> >
> > Elena
> >
> >
> >
>
next prev parent reply other threads:[~2002-12-10 17:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-25 20:27 Jim Blandy
2002-11-25 22:34 ` Eli Zaretskii
2002-12-09 19:55 ` Jim Blandy
2002-12-10 12:19 ` Eli Zaretskii
2002-12-09 22:13 ` Elena Zannoni
2002-12-10 8:13 ` Andrew Cagney
2002-12-10 9:14 ` Elena Zannoni [this message]
2002-12-10 11:39 ` Andrew Cagney
2002-12-10 12:43 ` Eli Zaretskii
2002-12-14 16:48 ` Jim Blandy
2002-12-23 1:25 ` Jim Blandy
2002-12-23 1:58 ` [repost] " Jim Blandy
2002-12-23 6:59 ` Eli Zaretskii
2003-01-23 23:04 ` Jim Blandy
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=15862.3912.243064.423628@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@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