[Top] [All Lists]

[patch flood] Debugging patches

Subject: [patch flood] Debugging patches
From: Daniel Jacobowitz <>
Date: Sat, 16 Jun 2001 12:41:02 -0700
User-agent: Mutt/1.3.16i
I've been actively working on GDB for the past two weeks now.  A good half
of the problems I've had have turned out to be kernel bugs; one of them
(shadowing res in the POKEUSR case in sys_ptrace) was already fixed in the
OSS tree and not in our local tree, but the others were still somewhat

The biggest one was the fact that passing arguments to the inferior in
floating point registers just didn't work.  I tracked this down to at least
three separate problems:
  - We would set last_task_used_math without clearing the ST0_CU1 bit in
    the previous task owning the FPU.  When that previous task swapped
    in again, it would use the existing FP registers, and lazy_fpu_switch
    would never be called.  This happened in signal.c and in ptrace.c.
  - ptrace didn't look for the FP registers in the right places.  This's
    been broken since the FPU emulator merge a while back.
  - We would create new processes with the ST0_CU1 bit already set if
    their parent process had it set.

Of course, the lazy switching isn't quite as useful as it could be, since
every program will eventually use the FPU if not build -msoft-float - I
think it's happening in glibc.  But we can possibly work around that later. 
It still does save a great number of switches, so it's worthwhile - when it

Other patches in my directory that I'm submitting along with that one:
 - kgdb-crash-resistant.diff
    This makes kgdb survive an attempt to dereference bad memory.  It only
    works after memory management has been set up, though.  It's possible
    to do it in such a way that it works even earlier - see PowerPC for an
    example.  We would have to set the fault handler temporarily, and
    basically longjmp out of the fault handler.  This is much more
    straightforward, and met my needs at the time.
 - mips-gdb-with-kgdb.diff
    There's no good reason to trigger kgdb on any trap whose origin is in
    userland - it's a kernel debugger, right?  So I save the traps, and
    pass them along to the old handlers if necessary.  This way kgdb won't
    stop on SIGTRAP when you set a breakpoint in gdb.
 - mips-rtsignal.diff
    Thought I'd sent this already... but I guess not.  setup_frame and
    setup_rt_frame build structures of different sizes, matching
    sys_sigreturn and sys_rt_sigreturn respectively.  Wouldn't it be useful
    if the frame setup_rt_frame built returned into the right function?

Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Attachment: fpu-sharing.diff
Description: Text document

Attachment: kgdb-crash-resistant.diff
Description: Text document

Attachment: mips-gdb-with-kgdb.diff
Description: Text document

Attachment: mips-rtsigreturn.diff
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>