This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Debugging X with GDB
- From: Jonathan Morton <jonathan dot morton at movial dot com>
- To: Daniel Jacobowitz <dan at codesourcery dot com>
- Cc: Bernie Innocenti <bernie at codewiz dot org>, dclark <dclark at gnu dot org>, xorg-devel at lists dot x dot org, rms at gnu dot org, gdb at sourceware dot org
- Date: Mon, 11 Jan 2010 16:26:16 +0200
- Subject: Re: Debugging X with GDB
- References: <E1NSMSM-0000oT-51@fencepost.gnu.org> <1263170536.29695.86.camel@giskard> <20100111140155.GD428@caradoc.them.org>
On Mon, 2010-01-11 at 09:01 -0500, Daniel Jacobowitz wrote:
> On Sun, Jan 10, 2010 at 07:42:16PM -0500, Bernie Innocenti wrote:
> > <airlied> I think X might change TTY state and piss gdb off
>
> I'd imagine this is it, but it's impossible to tell without debugging
> the TTY state.
>
> When you hit ^C, that doesn't necessarily cause anything to happen.
> The TTY subsystem sees ^C, and may or may not generate a SIGINT to the
> foreground process group depending on the tty settings; try checking
> using stty -F, for instance. Then the foreground process group is X,
> not GDB; if the SIGINT is blocked or ignored, it won't be delivered,
> so GDB can't intercept it at delivery.
>
> Using ^C is not always reliable.
A good trick might be to run X+gdb via SSH or a serial console. This is
then immune to VT switching semantics.
If X screws up sufficiently well to leave the graphics hardware in an
unusable state, or traps in gdb while you're watching it and is thus
unable to release the hardware to textmode, using SSH or serial console
also allows you to continue debugging.
--
------
From: Jonathan Morton
jonathan.morton@movial.com