lkml.org 
[lkml]   [2006]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [-mm patch] ptrace: make {put,get}reg work again for gs and fs
    Frederik Deweerdt wrote:
    > On Thu, Dec 21, 2006 at 11:22:05AM -0800, Jeremy Fitzhardinge wrote:
    >
    >> Frederik Deweerdt wrote:
    >>
    >>> Following the i386 pda patches, it's not possible to set gs or fs value
    >>> from gdb anymore. The following patch restores the old behaviour of
    >>> getting and setting thread.gs of thread.fs respectively.
    >>> Here's a gdb session *before* the patch:
    >>> (gdb) info reg
    >>> [...]
    >>> fs 0x33 51
    >>> gs 0x33 51
    >>> (gdb) set $fs=0xffff
    >>> (gdb) info reg
    >>> [...]
    >>> fs 0x33 51
    >>> gs 0x33 51
    >>> (gdb) set $gs=0xffffffff
    >>> (gdb) info reg
    >>> [...]
    >>> fs 0xffff 65535
    >>> gs 0x33 51
    >>>
    >>> Another one *after* the patch:
    >>> (gdb) info reg
    >>> [...]
    >>> fs 0xd8 216
    >>>
    >>>
    >> This doesn't look right. This is the kernel's %fs, not usermode's
    >> (which should be 0).
    >>
    >>
    >>> gs 0x33 51
    >>> (gdb) set $fs=0xffff
    >>> (gdb) info reg
    >>> [...]
    >>> fs 0xffff 65535
    >>> gs 0x33 51
    >>> (gdb) set $gs=0xffff
    >>> (gdb) info reg
    >>> [...]
    >>> fs 0xffff 65535
    >>> gs 0xffff 65535
    >>>
    >>>
    >> Hm. This shouldn't be possible since this is a bad selector, but I
    >> guess ptrace/gdb doesn't really know that. If you run the target (even
    >> single step it), these should revert to 0.
    >>
    >>
    > Here's a third session that looks better:
    >
    > (gdb) info reg
    > [...]
    > fs 0x0 0
    > gs 0x33 51
    > (gdb) set $fs=0xffff
    > (gdb) info reg
    > [...]
    > fs 0xffff 65535
    > gs 0x33 51
    > (gdb) set $gs=0xffff
    > (gdb) info reg
    > [...]
    > fs 0xffff 65535
    > gs 0xffff 65535
    > (gdb) n
    > Single stepping until exit from function main,
    > which has no line number information.
    > Cannot find user-level thread for LWP 10751: generic error
    > (gdb) set $gs=0x33
    > (gdb) set $fs=0
    > (gdb) n
    > Single stepping until exit from function main,
    > which has no line number information.
    > 0x08048c05 in __i686.get_pc_thunk.bx ()
    > (gdb) info reg
    > [...]
    > fs 0x0 0
    > gs 0x33 51
    >
    > This is a -mm1 kernel + your efl_offset fix + the attached patch.
    > So the problem came from putreg still saving %gs to the stack where
    > there's no slot for it, whereas getreg got things right.
    >
    > Regards,
    > Frederik
    >
    > Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
    >
    >
    > diff --git a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
    > index a803a49..d8f44db 100644
    > --- a/arch/i386/kernel/ptrace.c
    > +++ b/arch/i386/kernel/ptrace.c
    > @@ -89,14 +89,14 @@ static int putreg(struct task_struct *child,
    > unsigned long regno, unsigned long value)
    > {
    > switch (regno >> 2) {
    > - case FS:
    > + case GS:
    > if (value && (value & 3) != 3)
    > return -EIO;
    > - child->thread.fs = value;
    > + child->thread.gs = value;
    > return 0;
    > case DS:
    > case ES:
    > - case GS:
    > + case FS:
    > if (value && (value & 3) != 3)
    > return -EIO;
    > value &= 0xffff;
    >

    This patch is good. convert-i386-pda-code-to-use-%fs-fixes.patch
    touched this same code, but it didn't actually fix the problem.

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

    \
     
     \ /
      Last update: 2006-12-22 07:59    [W:0.031 / U:30.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site