From: Scott A Sumner <sasumner@juno.com>
To: insight@sourceware.cygnus.com
Subject: Re: Wrong Program Counter value when encountering a breakpoint -> SIGILL
Date: Mon, 22 May 2000 14:35:00 -0000 [thread overview]
Message-ID: <20000522.172439.-101741.2.sasumner@juno.com> (raw)
Paul,
I think you're on the right track. Why do you think that the "subtract
2" solution is "dirty"? I don't think it's so bad--it's what I do in my
68332 stub (I'm guessing that the 68340 is also a member of the CPU32
family of processors). Here's the comment--which pretty much says it
all--and the C code that does it for me:
/* the exception frame contains a program counter (which at this point
has been copied to gdb_register_file) that is 2 bytes past the trap #1
instruction that gdb inserted as a temporary breakpoint; need to
decrement the pc in the gdb register file by 2 so that upon return the
real instruction (temporarily covered by the trap #1) gets executed */
gdb_register_file[PC] -= 2;
If you want too see the surrounding code, you should be able to find it
on www.sourceforge.net ; search on "gdbstub" when you get there and then
do some looking for the cpu32 stub.
Regards,
Scott
On Mon, 22 May 2000 16:29:33 +0100 Paul_Heijman@eu.omron.com writes:
>
>
> Hi all,
>
> I'm at the moment working on the last few bugs of my mc68340-stub.
> My biggest problem now, is the following:
>
> When I set a breakpoint at a certain line or assembly instruction,
> and I press
> 'continue', GDB doesn't stop at the right address.
> If it, for example, had to stop at 0x33260, it stops at 0x33262.
> (always a
> difference of +2 bytes!).
>
> I know GDB sets breakpoints by replacing the original code with a
> TRAP #1
> instruction (2 bytes of machine code) and therefore this could be
> the reason why
> the program counter indicates a value of +2 above the breakpoint
> address.
> In the stub, there seems to be some kind of compensation for that.
> When the stub
> receives the continue or step command, it checks the frame cache for
> an existing
> version of the breakpoint-exception-frame. Thereby, it expects an
> offset of +2.
> But what if the breakpoint hasn't been encountered yet and doesn't
> exist in the
> frame cache?
>
> Anyway, it keeps on going wrong, and results (offcourse) in a SIGILL
> exception
> (Illegal Instruction) because the program counter is pointing
> somewhere between
> two instructions.
>
> Anyone have a clue what I might have done wrong in my stub, because
> I assume
> it's not a problem of GDB itself, since I never heard someone
> complain about it?
> I was thinking of simply subtracting '2' from the PC value whenever
> a breakpoint
> exception occurs, but I think this is a dirty solution (if it works)
> and I
> really want to find the cause.
>
> greetings,
> Paul.
next reply other threads:[~2000-05-22 14:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-22 14:35 Scott A Sumner [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-05-22 7:30 Paul_Heijman
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=20000522.172439.-101741.2.sasumner@juno.com \
--to=sasumner@juno.com \
--cc=insight@sourceware.cygnus.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).