From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: macro@codesourcery.com (Maciej W. Rozycki)
Cc: brobecker@adacore.com (Joel Brobecker),
palves@redhat.com (Pedro Alves),
gdb-patches@sourceware.org (GDB Patches)
Subject: Re: eliminate deprecated_insert_raw_breakpoint. what's left.
Date: Wed, 10 Sep 2014 16:45:00 -0000 [thread overview]
Message-ID: <201409101645.s8AGjLjg024077@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1409101553070.27075@tp.orcam.me.uk> from "Maciej W. Rozycki" at Sep 10, 2014 04:12:49 PM
Maciej W. Rozycki wrote:
> On Wed, 10 Sep 2014, Ulrich Weigand wrote:
> > Once OSF/1 and IRIX are gone, I hope all of the ECOFF/mdebug debug
> > format support can go as well (mipsread.c, mdebugread.c etc.) ...
>
> Some of that stuff will best stay, to support Procedure Descriptor
> Records used on MIPS ELF targets, including but not limited to Linux.
>
> These records are the only way to get backtracing, and consequently any
> reasonable control of the debuggee, to work from places that have debug
> information stripped, such as often when you interrupt your debuggee while
> waiting in a syscall (libc.so will often have no debug information
> included, as usually won't other system-installed shared libraries).
> Without that debugging is from my experience severely impeded -- you end
> up in the middle of nowhere and virtually all you can do is `continue' or
> `stepi', that'll in many cases merely put you back in the sleeping
> syscall.
>
> All MIPS ELF binaries produced by the GNU toolchain carry these PDR
> records along unless their exclusion has been explicitly requested from
> GAS (which is not the default and in most cases undesirable, these records
> are very lightweight and occupy little space).
>
> I have already identified `mdebugread.h' being the only piece required
> though -- in addition to `mips-mdebug-tdep.h' and `mips-mdebug-tdep.c'
> that were removed from our tree as a result of an unfortunate coincidence
> and have been maintained outside it for years now; they need some
> improvements at the time they are brought back too. Maybe `mdebugread.h'
> can be stripped down a bit and actually folded into `mips-mdebug-tdep.h'
> eventually.
This confuses me a bit, which is probably because I don't see what's in
mips-mdebug-tdep.c ...
Looking at alpha-mdebug-tdep.c, which I had hoped would be mostly equivalent,
this gets the PDR records from the magic MDEBUG_EFI_SYMBOL_NAME symbol, which
is created by mdebugread.c while parsing the .mdebug section in an ELF file
or while parsing an ECOFF file. So if we remove mdebugread.c, nobody will
ever set MDEBUG_EFI_SYMBOL_NAME, which means alpha-mdebug-tdep.c is a no-op.
Is this handled differently on mips? [ In general, it would be really
good if mips-mdebug-tdep.c is brought back into the tree if it is actually
being used in practice. Having people maintain stuff out-of-tree long-term
makes it hard to see if common code features are no longer used ... ]
Also, do you happen to know if on other (non- OSF/1) Alpha platforms the
.mdebug debug format is ever used?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next parent reply other threads:[~2014-09-10 16:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.1.10.1409101553070.27075@tp.orcam.me.uk>
2014-09-10 16:45 ` Ulrich Weigand [this message]
2014-09-10 19:11 ` Maciej W. Rozycki
2014-09-11 11:50 ` Ulrich Weigand
2014-09-08 17:46 Pedro Alves
2014-09-08 19:24 ` Joel Brobecker
2014-09-08 21:34 ` Joel Brobecker
2014-09-08 22:50 ` Pedro Alves
2014-09-09 0:25 ` Peter Schauer
2014-09-09 0:16 ` Peter Schauer
2014-09-09 11:39 ` Ulrich Weigand
2014-09-09 12:38 ` Peter Schauer
2014-09-09 21:25 ` Ulrich Weigand
2014-09-10 12:21 ` Joel Brobecker
2014-09-10 13:15 ` Ulrich Weigand
2014-09-10 15:22 ` Pedro Alves
2014-09-09 21:48 ` Ulrich Weigand
2014-09-10 12:29 ` Joel Brobecker
2014-09-10 14:45 ` Ulrich Weigand
2014-09-10 15:21 ` Pedro Alves
2014-09-10 15:50 ` Joel Brobecker
2014-09-10 16:00 ` Sergio Durigan Junior
2014-09-10 16:36 ` Ulrich Weigand
2014-09-10 15:50 ` Maciej W. Rozycki
2014-10-07 0:25 ` Stan Shebs
2014-09-09 17:33 ` Pedro Alves
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=201409101645.s8AGjLjg024077@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@codesourcery.com \
--cc=palves@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