Subject: Re: HELP : ptrace returns puzzling results

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 May 2000 13:36:20 +0200

On Mon, May 15, 2000 at 11:46:20AM -0700, Jun Sun wrote:

> I am writing a gdbserver for linux/mips.  The server can now talk with
> the gdb client, and can run to completion if you press 'c'.

Excellent.

> However, the gdb client reads some confusing register values.  I traced
> back to the gdbserver and found out that these values are returned from
> ptrace(), which seem wrong.  On the other hand, the native gdb must be
> using the same ptrace() to get register values.  I wonder why it works
> there.
> 
> Here is a sample output from gdbserver calling ptrace.  Note that PC
> value does not corresponds to the executable image.  sp also seems
> wrong.

> reg #29 ($29,sp) = 2147483120 (0x7ffffdf0)

The value of sp looks sane, it a value near the absolute top of the stack
at 0x80000000.

> reg #37 ($64,pc) = 263607008 (0x0fb652e0)

Also looks sane at first look, this value is in the typical address range
where the dynamic linker gets mapped.

Many of the registers in the dump you gave have a value of zero and that is
worrying me much more.  All the caller saved registers are zero, that
smells.

What kernel version are you using?

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 May 2000 22:10:30 +0200

On Tue, May 16, 2000 at 10:49:08AM -0700, Jun Sun wrote:

> However, step or next or setting another breakpoint do not work.  It
> appears that gdbserver calls ptrace with PTRACE_SINGLESTEP option, which
> is not implemented in the kernel I am using (it is v2.3.99-pre3).  Is
> this implemented in the latest version?  If not, is it difficult to add
> one?  Or can we get around without it?

PTRACE_SINGLESTEP is meant to be implemented using hardware single stepping.
That's something which most MIPS CPUs don't support.  It can be simulated in
userspace, so there is no point in putting it into the kernel ergo we won't
implement it.

There's actually a good number of CPUs which don't have hardware breakpoints
so you should check what gdbserver does for those other architectures.
The generic solution is to write a breakpoint into the logically next
instruction(s).  Usually that's at epc + 4 but there are branch instructions
to make live more entertaining ...

  Ralf