This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MIPS stub problem
- From: Michael Snyder <msnyder at vmware dot com>
- To: Qiu Feng <fallwind at gmail dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 16 Sep 2008 11:32:42 -0700
- Subject: Re: MIPS stub problem
- References: <4D79C9B593D04500AF1FD6DCEF5EB430@fqiux61>
Qiu Feng wrote:
Hi all,
I am implementing a stub for mips. I found epc always contains the position
of next instuction after the inserted "break", I wonder if PC client gdb
will take it into acount? Should I manually rollback the epc to the location
of replaced original instruction?
Hmmm. I'm rusty here, but I don't think that's the norm
for MIPS. What exact mips part is this?
There are two classes of processors -- those which point
to the trap instruction itself after taking a trap, and those
that point to the next instruction following the trap insn.
GDB accounts for this difference with a configuration variable
called DECR_PC_AFTER_BREAK ("decrement the PC after a breakpoint").
It's true for i386, for instance, but not normally for mips.
Another question, does pc side GDB only read local varibles by offset of SP
(should be $29)?
Again, my MIPS foo is rusty, but its likely that gdb may
also read local variables by offset from a frame pointer reg.