Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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