Re: [Kgdb-bugreport] [semi-OT] how to add int3 support to a bios
Status: Beta
Brought to you by:
jwessel
From: George A. <ge...@mv...> - 2005-08-27 00:03:33
|
Jim Cromie wrote: > George Anzinger wrote: > >> >> None of the above :) > > >> >> Still none of the above. See below... > > > 0-fer. At least Im consistent :-( > >>> >>> ~ >>> >>> <attach gdb here> >>> FATAL: read from term failed: Resource temporarily unavailable >> >> >> >> Hmmmm... Are you trying to use the serial port for something other >> than KGDB? That would not be wise... >> > not once Im trying to gdb the kernel. > > The serial port is busy supporting the boot itself. > Ive set my bios to prefer pxe boot, so if Ive got the ethernet plugged in, > the bios starts pxe, makes the RRQ request from tftpd, > and downloads pxelinux.0, but it wont run it > until the serial is connected. (no matter how long I wait) > > It looked to me like gdb punted the terminal emulator off the serial line, > ok to me. Until I connect with gdb, it looks like the kernel is just > waiting > for the right kind of data/command to be sent. > > If its not ok, then Im looking at boot race condition - I have to > disconnect > before the kernel gets to the serial part, which isnt very long. > My only choice then is to boot from a CF. Only one serial port? > > > >>> [jimc@harpo dilbert]$ >>> >>> >>> (gdb) target remote /dev/ttyUSB0 >>> 0xc01c70e2 in gdb_interrupt (irq=4, dev_id=0x0, regs=0xc033dfb8) at >>> arch/i386/lib/kgdb_serial.c:197 >> >> >> >> Since you got here, the int3 code is doing all it should do. >> > does this mean its impossible that its a do-nothing dummy function ? > or is a dummy function all thats needed ? ?? I don't understand your comment. int 3 is an instruction which causes a trap to the int3 handler in the kernel. It IS the breakpoint instruction. In order to get to this point the box had to take the serial interrupt, fetch the ^C, detect it and execute the int 3 instruction. The trap code then saves state and transfers control to kgdb which opens a dialog with gdb, during which it passes up the address of the breakpoint. Gdb then looked that address up and reported the function name and other info it gathered from the test box all over the serial line. > >>> /home/jimc/dilbert/lxbuild/linux-2.6.13-rc6-mm2-kgdb/arch/i386/lib/kgdb_serial.c:197:5300:beg:0xc01c70e2 >>> >>> warning: shared library handler failed to enable breakpoint >> >> >> >> This warning is gdb thinking it is doing user land code and looking >> for a shared lib it needs. For kernel land it is just noise, ignore it. >> >>> (gdb) bt >> >> >> >> Well... that is the most nasty command you could give. How about >> trying something easy, for example: >> >> (gdb) p kgdb_info <or some other thing you might actually want to >> see> >> > (gdb) p kgdb_info > $1 = {used_malloc = 0, called_from = 0xc010343b, entry_tsc = > 50315277349, errcode = 0, vector = 3, print_debug_info = 0} > (gdb) > >> Since this particular kgdb does not have the assembly debug >> annotations, the bt will have trouble. Try setting break points, >> continue, etc. > > > > (gdb) b register_chrdev_region > Breakpoint 1 at 0xc0151887: file fs/char_dev.c, line 170. > (gdb) c > >> >> Oh, and that "FATAL: read from term failed: Resource temporarily >> unavailable" seems to imply you are trying to share the port. Please >> don't. It will mess things up for either the kernel or kgdb, or both. >> > the above was done by disconnecting from the serial console b4 starting > gdb. > It appears to have partly worked. Is that sufficient to avoid the most > likely problems ? > Or should I actually try to win that race I mentioned. I don't see a problem if you are getting in and talking to kgdb as below. > > this seems ok too: > > ^C > Program received signal SIGTRAP, Trace/breakpoint trap. > 0xc01c8a63 in gdb_interrupt (irq=4, dev_id=0x0, regs=0xc0341fa4) at > arch/i386/lib/kgdb_serial.c:197 > (gdb) c > > > But what Im not getting is ability to ssh into the box, so I cant > trigger the break condition that im after. > Retrying the above, except with an immediate disconnnect after starting > kernel, > doesnt help - I get same gdb behavior, but ssh fails - no route to host, > ping -> destination host unreachable. That is a horse of a different color and has nothing to do with kgdb. If kgdb is disabled does the net come up? > -- George Anzinger ge...@mv... HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ |