Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Peter Schauer <peterschauer@gmx.net>
To: palves@redhat.com (Pedro Alves)
Cc: brobecker@adacore.com (Joel Brobecker),
	  gdb-patches@sourceware.org (GDB Patches)
Subject: Re: eliminate deprecated_insert_raw_breakpoint.  what's left.
Date: Tue, 09 Sep 2014 00:25:00 -0000	[thread overview]
Message-ID: <201409090025.s890PPJo007192@licht.localdomain> (raw)
In-Reply-To: <540E32AA.70705@redhat.com> from "Pedro Alves" at Sep 08, 2014 11:50:18 PM

> 
> On 09/08/2014 10:34 PM, Joel Brobecker wrote:
> 
> > I was looking at how to replace that call, but I am not sure
> > how to fix the code up, though. Perhaps we could just write
> > the breakpoint instruction in by hand, rather than go through
> > the breakpoint module? After all, it is already doing almost
> > everything else by hand!
> 
> Indeed.
> 
> > In fact, looking at the code again now, I'm a little more tempted
> > to see what happens if we remove it ;-).
> 
> Me too.  And seriously.  :-)
> 
> I traced it back to I think the original rs6000 port, in 1991...
> 
> commit 41abdfbd2de07837ba8088092765154eaa66351d
> Author: John Gilmore <gnu@cygnus>
> Date:   Tue Nov 12 15:50:47 1991 +0000
> 
>     * rs6000-pinsn.c, rs6000-tdep.c, rs6000-xdep.c, tm-rs6000.h,
>     xm-rs6000.h:  New files.
>     * xcoffexec.c:  New file for handling AIX shared libraries.
> 
> 
> 
> We already see this then, in rs6000-xdep.c:
> 
> +       /* execute one dummy instruction (which is a breakpoint) in inferior
> +          process. So give kernel a chance to do internal house keeping.
> +         Otherwise the following ptrace(2) calls will mess up user stack
> +         since kernel will get confused about the bottom of the stack (%sp) */
> +
> +       exec_one_dummy_insn ();
> 
> 
> This sounds like working around a (very) old kernel bug...

No, not a bug, but consequences of a very peculiar ptrace implementation,
at least up until and including AIX 4.3.

See my other post for a more detailed explanation.

> I can't believe anything resembling a modern system would need
> such a monstrosity!  :-)  I vote just removing all that.

Me too, provided that newer AIX versions have a better ptrace implementation,
making this  monstrosity unnecessary.

-- 
Peter Schauer			Peter.Schauer@mytum.de


  reply	other threads:[~2014-09-09  0:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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 18:59               ` New deprecation procedure Pedro Alves
2014-09-11 19:03                 ` Joel Brobecker
2014-09-12  8:51                   ` Ulrich Weigand
2014-09-10 15:50           ` eliminate deprecated_insert_raw_breakpoint. what's left Maciej W. Rozycki
2014-09-10 16:12             ` [IRIX] eliminate deprecated_insert_raw_breakpoint uses Pedro Alves
2014-09-10 22:44               ` Joel Brobecker
2014-09-10 23:02                 ` Pedro Alves
2014-09-11  3:27                   ` Joel Brobecker
2014-09-12 19:34                     ` Pedro Alves
2014-09-12 20:23                       ` Joel Brobecker
2014-10-07  0:25         ` eliminate deprecated_insert_raw_breakpoint. what's left Stan Shebs
2014-09-09 17:33 ` Pedro Alves
     [not found] <alpine.DEB.1.10.1409101553070.27075@tp.orcam.me.uk>
2014-09-10 16:45 ` Ulrich Weigand
2014-09-10 19:11   ` Maciej W. Rozycki
2014-09-11 11:50     ` Ulrich Weigand

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=201409090025.s890PPJo007192@licht.localdomain \
    --to=peterschauer@gmx.net \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --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