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

[Christian Schmidt]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/