Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Randolph Chung <randolph@tausq.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED
Date: Wed, 01 Dec 2004 23:32:00 -0000	[thread overview]
Message-ID: <41AE5434.9050901@gnu.org> (raw)
In-Reply-To: <20041201223243.GK6359@tausq.org>

Randolph Chung wrote:
>>Anyway, trying modifying gdbarch_read_pc and unwind_pc (I suspect you 
>>need to modify both - which is a bug) to read something like:
>>
>>	if (instruction nullified)
>>		return next-pc
>>	else
>>		return this-pc
> 
> 
> i did s/next-pc/prev-pc/ instead... still seems a bit hacky to me, but
> it does seem to work.

> @@ -1049,7 +1089,17 @@ hppa_target_read_pc (ptid_t ptid)
>    if (flags & 2)
>      return read_register_pid (31, ptid) & ~0x3;
>  
> -  return read_register_pid (HPPA_PCOQ_HEAD_REGNUM, ptid) & ~0x3;
> +  pc = read_register_pid (HPPA_PCOQ_HEAD_REGNUM, ptid) & ~0x3;
> +
> +  /* If the current instruction is nullified, then we are effectively
> +     still executing the previous instruction.  Pretend we are still
> +     there.  This is needed when single stepping; if the nullified instruction
> +     is on a different line, we don't want gdb to think we've stepped onto
> +     that line.  */
> +  if (ipsw & 0x00200000)
> +    pc -= 4;
> +
> +  return pc;
>  }

On the SPARC architecture you can do things like:

	branch foo
	branch bar

which leads to more warped combinations such as (assuming I've got my 
diagram right):

f+0:	branch x+c
f+4:	branch x+8

x+0:	branch e+4
x+4:	branch e+0
x+8:    branch x+0
x+c:    branch,annulled x+4

and I'm fairly sure that results in:

f+0  f+4 [x+c]
      f+4  x+c [x+8]
           x+c  --- [x+4]
	       ---  x+4 [x+8] <-------- {npc+4}
                     x+4  x+8 [e+0]
                          x+8  e+0 [x+0]
                               e+0  x+0 ....

and hence the ``---'' anulled instruction at x+8 has a prev-pc of x+c 
(pc+4) and not x+4 (pc-4).

This is why I was thinking that next-pc is better (but the above could 
be wrong - my sparc is very very rusty :-().

Either way, yes ok (and thanks!)

Andrew

PS: No it's not a hack, XXX_pc projects the hardware onto an idealized 
machine, there are always perverse edge cases.

PPS: A gdb.arch/ addition to tickle the basic edge case would be a 
helpful way of capturing this knowledge.


  reply	other threads:[~2004-12-01 23:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-18  0:02 Randolph Chung
2004-11-18 14:26 ` Andrew Cagney
2004-11-18 16:21   ` Randolph Chung
2004-11-18 16:56     ` Mark Kettenis
2004-11-19  9:25       ` Orjan Friberg
2004-11-23 17:50       ` Randolph Chung
2004-11-23 19:33         ` Mark Kettenis
2004-11-28 17:26         ` Andrew Cagney
2004-11-28 18:41           ` Randolph Chung
2004-11-28 19:55             ` Andrew Cagney
2004-11-29  3:30               ` Randolph Chung
2004-11-29 15:12                 ` Andrew Cagney
2004-11-30  6:56                   ` Randolph Chung
2004-11-30 14:51                     ` Andrew Cagney
2004-11-30 16:44                       ` Randolph Chung
2004-11-30 16:59                         ` Andrew Cagney
2004-11-30 17:38                           ` Randolph Chung
2004-12-01 21:29                             ` Andrew Cagney
2004-12-01 22:33                               ` Randolph Chung
2004-12-01 23:32                                 ` Andrew Cagney [this message]
2004-12-02  5:24                                   ` Randolph Chung
2004-12-02 14:27                                     ` Daniel Jacobowitz
2004-12-03 18:11                                     ` Andrew Cagney
2004-12-03 18:15                                       ` Randolph Chung
2004-12-03 18:57                                         ` Daniel Jacobowitz
2004-12-03 19:57                                           ` Randolph Chung
2004-12-03 21:40                                       ` Randolph Chung
2004-12-03 21:58                                         ` Andrew Cagney
2004-12-03 22:52                                           ` Daniel Jacobowitz
2004-12-04  0:00                                           ` Randolph Chung
2004-12-04  0:55                                           ` Randolph Chung
2004-12-04 11:27                                             ` Mark Kettenis
2004-12-01  6:19                   ` Randolph Chung
2004-12-01 17:11                     ` Daniel Jacobowitz
2004-12-01 17:17                       ` Randolph Chung
2004-12-01 17:19                         ` Daniel Jacobowitz
2004-12-01 17:25                           ` Randolph Chung
2004-12-01 17:28                             ` Daniel Jacobowitz
2004-12-01 17:30                               ` Randolph Chung
2004-12-01 17:35                               ` Randolph Chung
2004-12-01 18:14                                 ` Randolph Chung
2004-12-01 21:25                       ` Andrew Cagney
2004-12-01 13:32 Paul Schlie
2004-12-01 16:25 Randolph Chung

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=41AE5434.9050901@gnu.org \
    --to=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=randolph@tausq.org \
    /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