Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>,
	"Joseph S. Myers"	<joseph@codesourcery.com>
Cc: Tom Tromey <tromey@redhat.com>,
	Stan Shebs <stanshebs@earthlink.net>,
	<gdb-patches@sourceware.org>
Subject: Re: [PATCH] remove ECOFF
Date: Tue, 20 Aug 2013 16:19:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1308201643330.8514@tp.orcam.me.uk> (raw)
In-Reply-To: <201308201519.r7KFJwIa000280@glazunov.sibelius.xs4all.nl>

On Tue, 20 Aug 2013, Mark Kettenis wrote:

> > Maciej> The MIPS target wants to use minimal ECOFF debug information
> > Maciej> that is stored in ELF binaries in the so called PDR or Procedure
> > Maciej> Descriptor Record section [1].
> > 
> > Maciej>  Support for PDR unwinding (mips-mdebug-tdep.[ch]) was removed a
> > Maciej> while ago from GDB sources
> > 
> > Maciej>  I think this is a serious shortcoming of GDB on the MIPS target and a 
> > Maciej> good argument in favour to having this PDR unwinding support.
> > 
> > It's fine by me if you want to resurrect all the code.  I don't even
> > mind dropping my patch.
> > 
> > If you have a way to test the ECOFF code, then great.  I'd appreciate it
> > if you could volunteer to test whatever patches modify these readers.
> 
> I think Maciej concerns for MIPS pretty much mirror my concerns for
> Alpha.  I should be able to test stuff on Alpha, but not in the next
> three weeks.

 Following Stan's suggestion I had a look through mips-mdebug-tdep.[ch] we 
have and it seems to me its reliance on mdebugread.[ch] is minimal.  It 
imports the definition of `struct mdebug_extra_func_info' from 
mdebugread.h, but otherwise handles .pdr sections itself.  So it looks to 
me my concern may have been premature.

 I think moving the struct definition over to mips-mdebug-tdep.h shouldn't 
be a problem and the rest of ECOFF support can go then.  I'll see yet if 
all this PDR stuff builds and works with your patch applied.  I don't have 
a real ECOFF target to test with.

On Tue, 20 Aug 2013, Joseph S. Myers wrote:

> Rather than resurrecting this legacy MIPS-specific support, it would seem 
> a lot better on Linux to generate .eh_frame by default (as on various 
> other architectures) and phase out any remaining PDR generation there.  
> For glibc 2.18 the eh_frame CFI information is present in many assembly 
> sources and it could be added to the rest.

 That may be a long-term plan, however as I've noted, support for ECOFF 
function frame annotation in MIPS GAS has been there since forever and has 
been extensively documented in MIPS assembly manuals coming from various 
sources, and therefore is present in virtually all MIPS assembly code out 
there.  OTOH CFI information is mostly lacking from handcoded assembly 
sources.  Therefore while I think adding such CFI information will be 
valuable I also think there's value in having PDR unwinding handled as 
well.

 There are also the bare-iron targets whose users may not necessarily be 
happy to have extra .eh_frame data in their binaries.

 My understanding of the reason why mips-mdebug-tdep.[ch] were removed in 
the first place was the files had never been properly wired into the MIPS 
targets we keep supporting and their only users were obsoleted at one 
point, making mips-mdebug-tdep.[ch] orphan.

  Maciej


  reply	other threads:[~2013-08-20 16:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19 18:19 Tom Tromey
2013-08-19 18:51 ` Mark Kettenis
2013-08-19 18:57   ` Tom Tromey
2013-08-19 19:02     ` Tom Tromey
2013-08-19 19:41       ` Joel Brobecker
2013-08-19 21:21 ` Maciej W. Rozycki
2013-08-19 23:22   ` Stan Shebs
2013-08-20 15:12   ` Tom Tromey
2013-08-20 15:20     ` Mark Kettenis
2013-08-20 16:19       ` Maciej W. Rozycki [this message]
2013-08-20 15:19   ` Joseph S. Myers

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=alpine.DEB.1.10.1308201643330.8514@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=joseph@codesourcery.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=stanshebs@earthlink.net \
    --cc=tromey@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