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
next prev parent 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