ptrace (PTRACE_GETREGS, ...) discrepancy for x86 emulation on x86_64?

[Christian Schmidt <lkml@digadd.de>]

Hi all,

I'm currently toying around a bit with the ptrace api on linux. First, a 
few specs:

Kernel 2.6.24.4, glibc 2.7, x86_64 arch.

I am using the 32bit emulation on this to debug a program "the old way", 
putting "int3" opcodes into the code via PTRACE_POKE and waiting for the 
trap. In theory, I should than use PTRACE_GETREGS, decrement the EIP 
register, restore the original opcode, write the registers back with 
PTRACE_SETREGS, and the program should continue.
What I see instead is that regs.eip if 0xffffffff, and the next register 
contains the expected code offset.

I wonder if the reason is:

/usr/src/linux-2.6.24.4/include/asm-x86/ptrace.h:

struct pt_regs {
         long ebx;
         long ecx;
         long edx;
         long esi;
         long edi;
         long ebp;
         long eax;
         int  xds;
         int  xes;
         int  xfs;
         /* int  xgs; */
         long orig_eax;
         long eip;
         int  xcs;
         long eflags;
         long esp;
         int  xss;
};

/usr/src/linux-2.6.24.4/arch/x86/ia32/ptrace32.c:

static int putreg32(struct task_struct *child, unsigned regno, u32 val)
{
         int i;
         __u64 *stack = (__u64 *)task_pt_regs(child);

         switch (regno) {
         case offsetof(struct user32, regs.fs):
                 if (val && (val & 3) != 3) return -EIO;
                 child->thread.fsindex = val & 0xffff;
                 break;
         case offsetof(struct user32, regs.gs):
                 if (val && (val & 3) != 3) return -EIO;
                 child->thread.gsindex = val & 0xffff;
                 break;

So GS is still set (somewhere), though not defined for userspace. Am I 
correct, and should I fix my includes? After uncommenting the "int xgs;" 
above the program works.

Regards,
Chris

PS: I'm not subscribed, direct CC: to me is appreciated