Hello! I''d like to use pdb but it''s not quite working as expected. The 1st issue is that jumping to the debugger by pressing ''D'' doesn''t work because this leaves serial interrupts blocked. Maybe this is only the case because I''m using lo/hi muxing but my guess is that it''s not. I''ve implemented a work around which seems to work: if pdb is entered by the keypressed handler it will call a new serial_getc function if there''s no input in the rx ring. I''m not sure if this is also necessary when interacting with the debugger on a breakpoint or after a crash... 2nd issue is that the debugger doesn''t work when hitting a breakpoint (and possibly after a crash) which raises my question if anybody is actually using the pdb code which is in unstable ;-) Finally, nsplitd seems to be missing the part which connects it to the serial port (it wants to connect to a host:port, I guess on a terminal server...). The 2nd attachment is a program which presents the cleared-bit connection on stdin/stdout and the set-bit connection on a tcp port (option -g to set the port). It should also work from inetd or as a server (option -p to set the server port) but I haven''t really tested those modes (I at first implemented the inetd/server modes and then decided that I prefer stdin/stdout...). -- Christian Limpach <chris@pin.lu>
> Hello! > > I''d like to use pdb but it''s not quite working as expected. > > The 1st issue is that jumping to the debugger by pressing ''D'' doesn''t work > because this leaves serial interrupts blocked. Maybe this is only the > case because I''m using lo/hi muxing but my guess is that it''s not. I''ve > implemented a work around which seems to work: if pdb is entered by the > keypressed handler it will call a new serial_getc function if there''s no > input in the rx ring. I''m not sure if this is also necessary when > interacting with the debugger on a breakpoint or after a crash...I''ve fixed this a better way, by enabling interrupts before calling the pdb handler. Let me know if it still doesn''t work.> 2nd issue is that the debugger doesn''t work when hitting a breakpoint (and > possibly after a crash) which raises my question if anybody is actually > using the pdb code which is in unstable ;-)I don''t think PDB is entered on a crash -- it currently appears only to be hooked into the int3 and debug exception handlers. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I''ve fixed this a better way, by enabling interrupts before calling > the pdb handler. Let me know if it still doesn''t work.No it doesn''t work, at least not for the "jump to the debugger by pressing D" case. Maybe because you only enabled interrupts during traps but not during interrupts? AFAICT there''s also some locking/flag setting which might prevent further interrupts while the handler is still running (if I''m looking at the right code, do_IRQ in xen/arch/i386/irq.c). I considered enabling interrupts at first but I couldn''t exclude re-entrance issues. Also I think that it''s not the right thing to do in this case: if you''re using the debugger on Xen, you don''t want interrupts enabled. I think you''d actually want them explicitly disabled (as opposed to the previous/current implicit disabling). christian ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > I''ve fixed this a better way, by enabling interrupts before calling > > the pdb handler. Let me know if it still doesn''t work. > > No it doesn''t work, at least not for the "jump to the debugger by pressing > D" case. Maybe because you only enabled interrupts during traps but not > during interrupts? AFAICT there''s also some locking/flag setting which > might prevent further interrupts while the handler is still running (if I''m > looking at the right code, do_IRQ in xen/arch/i386/irq.c). > > I considered enabling interrupts at first but I couldn''t exclude re-entrance > issues. Also I think that it''s not the right thing to do in this case: if > you''re using the debugger on Xen, you don''t want interrupts enabled. I > think you''d actually want them explicitly disabled (as opposed to the > previous/current implicit disabling).Hmmmm... maybe you''re right. :-) Certainly I''ve changed my mind about yesterday''s fix. I''ll back it out and do something along the lines of what you posted in the first place. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > I''ve fixed this a better way, by enabling interrupts before calling > > the pdb handler. Let me know if it still doesn''t work. > > No it doesn''t work, at least not for the "jump to the debugger by pressing > D" case. Maybe because you only enabled interrupts during traps but not > during interrupts? AFAICT there''s also some locking/flag setting which > might prevent further interrupts while the handler is still running (if I''m > looking at the right code, do_IRQ in xen/arch/i386/irq.c). > > I considered enabling interrupts at first but I couldn''t exclude re-entrance > issues. Also I think that it''s not the right thing to do in this case: if > you''re using the debugger on Xen, you don''t want interrupts enabled. I > think you''d actually want them explicitly disabled (as opposed to the > previous/current implicit disabling). > > christian >Okay, I checked in a fix somewhat like the one you initially proposed. Fancy giving it another spin? :-) -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Okay, I checked in a fix somewhat like the one you initially > proposed. Fancy giving it another spin? :-)Ok, this works. Thanks! And breakpoints now work occasionally... I think the problem is that my test machine is 2-CPU SMP: (from a log of the ''wire'' between gdb and Xen, Xen->gdb is in [], everything else is gdb->Xen) $Mfc510390,1:cc#a5[+][$][O][K][#][9][$][S][a][0] Here gdb sets the breakpoint by writing 0xcc to the breakpoint address. Xen then would acknowledge this by replying with OK by sending "+$OK#9a" but it doesn''t get to entirely send the reply since I guess the breakpoint is hit on the other CPU? (the breakpoint is on __enter_scheduler btw) The log should look like this: $Mfc510390,1:cc#a5[+][$][O][K][#][9][a]+$Hc0#db[+][$][O][K][#][9][a]+$C0a#d4 [+][$][S][0][5][#][b][8]+ Here the reply works and gdb sends commands Hc0 and C0a to continue execution and only then Xen hits the breakpoint and sends $S05#b8 which gdb then acknowledges with a +... I guess we''d have to IPI the other CPUs when we hit a breakpoint? christian ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel