Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>,
	Mark Kettenis <kettenis@chello.nl>,
	kevinb@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 1 of 4
Date: Sat, 11 Oct 2003 02:17:00 -0000	[thread overview]
Message-ID: <1031011021736.ZM1457@localhost.localdomain> (raw)
In-Reply-To: Andrew Cagney <ac131313@redhat.com> "Re: [RFC] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 1 of 4" (Oct  8,  2:26pm)

On Oct 8,  2:26pm, Andrew Cagney wrote:

> I also wonder if PPC64 GDB could use this to do the descriptor -> 
> function address transformation that I described in:
> http://sources.redhat.com/ml/gdb-patches/2003-09/msg00415.html

I suppose it could, although that's definitely not the (well, my)
intended purpose of ADJUST_BREAKPOINT_ADDRESS.  If we do wind up using
it for this purpose, we'll want to disable the warning messages.  It
makes no sense to have a breakpoint on the descriptor, so when used in
this way, it'd definitely be the case that gdb is just doing the
"right thing".  It'd be easy enough to add an argument to the method
which passes indicating the kind of adjustment.  Off hand, I think a
tri-state value makes sense:


    1) the adjustment can potentially alter expected behavior making
       user warnings manditory.  E.g, FR-V architecture constraints.

    2) benign, the breakpoint's location has been moved slightly,
       but there should be no change in expected behavior.  Perhaps
       an informational message could be displayed for this state.
       E.g.  - maybe - that old v850 problem that Gary Thomas once
       told us about in which he had to sometimes place breakpoints
       that were larger than the smallest instruction.

    3) the adjustment was necessary because to place a breakpoint on
       the original address is wrong.  E.g, function descriptors -
       it makes no sense to place a breakpoint on the function descriptor,
       but it does make sense to place a breakpoint on the code address
       that the descriptor points to.

Kevin


  reply	other threads:[~2003-10-11  2:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-04  0:28 Kevin Buettner
2003-10-06 12:49 ` Mark Kettenis
2003-10-06 14:37   ` Andrew Cagney
2003-10-06 15:37   ` Kevin Buettner
2003-10-06 21:09     ` Mark Kettenis
2003-10-08 18:26       ` Andrew Cagney
2003-10-11  2:17         ` Kevin Buettner [this message]
2003-10-11 16:17           ` Andrew Cagney
2003-10-13 23:43 ` Kevin Buettner

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=1031011021736.ZM1457@localhost.localdomain \
    --to=kevinb@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@chello.nl \
    /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