From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13696 invoked by alias); 11 Jan 2010 00:42:31 -0000 Received: (qmail 13683 invoked by uid 22791); 11 Jan 2010 00:42:30 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from trinity.develer.com (HELO trinity.develer.com) (83.149.158.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jan 2010 00:42:25 +0000 Received: (qmail 28598 invoked from network); 11 Jan 2010 00:42:21 -0000 Received: from c-24-91-152-135.hsd1.ma.comcast.net (HELO ?10.162.44.98?) (bernie@24.91.152.135) by trinity.develer.com with ESMTPA; 11 Jan 2010 00:42:21 -0000 Subject: Debugging X with GDB From: Bernie Innocenti To: rms@gnu.org Cc: dclark , gdb@sourceware.org, xorg-devel@lists.x.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Jan 2010 00:42:00 -0000 Message-ID: <1263170536.29695.86.camel@giskard> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00099.txt.bz2 Cc'ing the gdb and xorg lists, in case someone knows better. On Tue, 2010-01-05 at 22:21 -0500, Richard Stallman wrote: > The version of GDB installed is 6.8, so I guess that is rather old. > It is important for MIPS gNewSense to have a version of GDB > which is well maintained for the MIPS. I asked on #xorg-devel about our issue with ^C not working in gdb. So, we seems to have encountered a long-standing problem, not related to MIPS or a specific version of GDB: is it still to be expected that gdb can't stop the X server with ^C ? I'm debugging on a mips platform... it may very well be a platform bug ajax, airlied: maybe one of you knows? bernie: I'm not sure its ever worked for me, I generally kill -INT `pidof Xorg` it works if you attach to a running server, not if you start through gdb whot: indeed, I just discovered it I wonder if it's a bug in gdb airlied: thanks for the suggestion, I thought it was just me :) I think X might change TTY state and piss gdb off airlied: oh, good point (although I'm debugging over ssh, it would be a bug for X to attempt changing that tty rather than the actual console) xf86DrvMsg(pScrn->scrnIndex, from, "Using %sware Cursor\n", lol ^c'ing a running server is expected to work, regardless of how you attached gdb. if it doesn't it's a bug in gdb or in the kernel's signal delivery code nwnk: I have "NoTrapSignals", but it doesn't help nwnk: I suspect a bug in gdb... wouldn't be the first nwnk: as a matter of fact, X is resilient to ^C even when running standalone really? that'd be news to me ^c in gdb doesn't send sigint to the traced process though, it sends sigint to gdb whot: only when it's sort of crashed :-) whot: or maybe it's because of the NoTrapSignals jcristau: right; gdb should then handle it according to whatever you set for 'signal SIGINT', which defaults to 'stop' excuse me, 'handle SIGINT' but what often seems to happen is the signal just gets ignored by both -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/