From: Brian Ford <ford@vss.fsi.com>
To: gdb@sources.redhat.com
Subject: Re: Are mixed debug formats in one exe supported?
Date: Wed, 24 Mar 2004 07:12:00 -0000 [thread overview]
Message-ID: <Pine.GSO.4.58.0403231737350.17486@thing1-200> (raw)
In-Reply-To: <Pine.GSO.4.58.0403231720070.17486@thing1-200>
On Tue, 23 Mar 2004, Brian Ford wrote:
> BTW, please CC me as I'm not subscribed to the list. Thanks.
>
> On Tue, 23 Mar 2004, Daniel Jacobowitz wrote:
>
> > On Tue, Mar 23, 2004 at 02:41:01PM -0600, Brian Ford wrote:
> > > I am trying to add DWARF2 support to PE/COFF for Cygwin/Mingw. They
> > > currently use stabs.
> > >
> > > While testing, executables end up having mixed stabs/DWARF2 debugging
> > > info if any system/gcc/previously compiled static libs are linked in.
> > > The result causes gdb to SEGV while traversing the partial symbol tables
> > > looking for symbol main.
> > >
> > > The problem is that init_psymbol_list is called for the executable twice
> > > due to mainline being set at dbxread.c:562, and again at
> > > dwarf2read.c:1076.
> > >
> > > So, the question. Is this meant to work? I assume the reason mainline is
> > > used here is:
> > >
> > > /* If we are reinitializing, or if we have never loaded syms yet, init */
> > >
> > > Why does reinitializing not clean up after itself (ie. reset the
> > > [global|static]_psymbols.size to 0)? Is that a leak?
> > >
> > > I'm going to keep digging, but since I have zero knowledge of gdb
> > > internals, I thought I'd ask and save some time. Thanks.
> >
> > I can't answer any of the more detailed questions, but yes, this is
> > supposed to work. It's easy to produce binaries with both stabs and
> > DWARF-2 on GNU/Linux, and it generally works OK.
> >
> I almost see why. Can someone please tell me why this comment above
> elfstab_build_psymtabs is true for the DWARF part?
>
> This ELF file has already been processed to get its minimal symbols,
> and any DWARF symbols that were in it.
>
> ie. What gaurantees that DWARF is processed before stabs? I can't see
> that yet. If I can understand that, I think I can easily fix my problem.
>
> Thanks again.
>
Sorry to follow up my own post, but I'm now even more confused.
From what I can see, the order (for elf) is gauranteed to be ECOFF, stabs,
DWARF2, DWARF, DWARF2 frame info. So, that comment just looks wrong. And, I
still don't understand why it works on Linux.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
next prev parent reply other threads:[~2004-03-23 23:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-23 22:40 Brian Ford
2004-03-23 22:42 ` Daniel Jacobowitz
2004-03-23 23:47 ` Brian Ford
2004-03-24 7:12 ` Brian Ford [this message]
2004-03-24 9:25 ` Brian Ford
2004-03-24 10:29 ` Daniel Jacobowitz
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=Pine.GSO.4.58.0403231737350.17486@thing1-200 \
--to=ford@vss.fsi.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