[uClinux-dev] gdbserver kills the shell?

John Williams jwilliams at itee.uq.edu.au
Tue Oct 11 23:32:43 EDT 2005


Hi Stuart,

Stuart Hughes wrote:

> John Williams wrote:
> 

>> take a look at include/asm-microblaze/ptrace.h - or asm-v850 which I
>> based it on.  All you do is define these magic values relative to the
>> last "real" one:
>>
>> /* These are `magic' values for PTRACE_PEEKUSR that return info about
>> where a process is located in memory.  */
>> #define PT_TEXT_ADDR    (PT_SIZE + 1)
>> #define PT_TEXT_LEN     (PT_SIZE + 2)
>> #define PT_DATA_ADDR    (PT_SIZE + 3)
>>
> I did see those, I'm having trouble figuring how to compute the value of
> PT_SIZE for m68knommu

[snip]

> Looking back at the platform I'm working on (m68knommu), I see that
> there are some #ifdefs in the struct pt_regs, so I came up with the idea
> of using 'sizeof(struct pt_regs)'.  The problem is that this comes out
> at 52, which looks plausible, but this differs wildly from the value I
> extracted from the original code (the first space after pt_regs):
> 
> #define PT_TEXT_ADDR 49*4  which I extracted from the original code
> which was:
> 
> code_start = ptrace (PTRACE_PEEKUSER, inferior_pid,
>              (PTRACE_ARG3_TYPE) 49*4, 0);
> 
> Can you (or anyone see) why these 2 values are so wildly different (49*4
> = 196 versus 52 for sizeof(pt_regs)).  Clearly the 49*4 value in the
> original seems to work (or did I just get lucky?).

If you look in arch/m68knommu/kernel/ptrace.c, handling of the
PTRACE_PEEKUSR case, you can see some code that shifts the request
address right 2 places, ie divides by 4, allowing it to form an index
into the process's stack frame.  That explains the factor of 4
difference you are seeing.

It looks like these PEEKUSR/POKEUSR operations, and the offsets into the
various structures, are pretty well hard-coded.

You may get by just by reflecting these hard coded offsets in
include-asm-m68knommu/ptrace.h, including that file in
arch/m68knommu/kernel/ptrace.c, and substituting those nasty hard-coded
numeric values with equally hard-coded, but not so nasty, #define'd
parameters.  Then, make sure that gdbserver/linux-m68k-low.c includes
asm/ptrace.h, and all should be groovy, or at least close to it.

> Another slight issue is also that using:
> 
>  #define PT_TEXT_ADDR    (PT_SIZE + 1)
> 
> etc is that you need to include <asm/ptrace.h> rather than just
> <sys/ptrace.h>, I thought including kernel headers in userspace directly
> was now deprecated ?

Yes, including kernel headers in user space is strongly deprecated.  My
argument however would be that something as low level as a
process/thread debuger is about as intimately tied to the kernel as an
application can be.  The fact that gdbserver/linux-*-low.c all include
asm/ptrace.h supports my assertion :)

Regards,

John




More information about the uClinux-dev mailing list