From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18108 invoked by alias); 24 Dec 2005 16:23:07 -0000 Received: (qmail 18101 invoked by uid 22791); 24 Dec 2005 16:23:07 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 24 Dec 2005 16:23:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EqCAg-00037c-A1 for gdb@sourceware.org; Sat, 24 Dec 2005 11:23:02 -0500 Date: Sat, 24 Dec 2005 16:23:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Stepping over longjmp presumably broken for glibc Message-ID: <20051224162302.GA11929@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20051222211734.GA13178@nevyn.them.org> <20051223132039.GA24942@nevyn.them.org> <20051223152021.GA26794@nevyn.them.org> <20051223170913.GA28791@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00193.txt.bz2 On Fri, Dec 23, 2005 at 07:46:09PM +0200, Eli Zaretskii wrote: > > Date: Fri, 23 Dec 2005 12:09:13 -0500 > > From: Daniel Jacobowitz > > > > with the added downside of greater coordination between the > > debugger and runtime (additional points of failure). > > We already have this downside (in many parts of GDB, not only in this > particular situation), so continuing with that won't be a change for > the worse. Sorry, but I think it will. The only two places that come to mind for glibc are the shared library list and libthread_db; both are constant sources of bugs and aggrevation. Not so much for the native case, but I work with a lot of people who use remote debugging, and answer many questions about it on gdb@. Also, as a general principle, I aim to keep the debugger as fully isolated from the debuggee as possible. I spend a lot of time debugging the C runtime, and the bits where GDB tries to "cooperate" with it are extremely frustrating in that case. When I have some more time for it, I'll be further reducing our dependence on glibc for threads. > If glibc maintainers actively fight the debugger's ability to debug > their code, we will never succeed in catching up with them. So I'd > rather they stopped with that attitude and started cooperating with > us. I can ask RMS to try to influence the glibc team, if you think > this will help. I'm not sure where you're going with this. It's not greater _human_ coordination that I'm objecting to, it's greater _machine_ coordination; version skew between glibc and gdb, support for old and new versions, et cetera. The hooks would not get a lot of use, and would be very complicated - I can say the former based on the fact that no one's noticed the problem yet (I found it by code inspection), and the latter based on studying the implementation. Complicated means fragile. I think that a solution which does not rely on support from the runtime being debugged is inherently superior to one which does. -- Daniel Jacobowitz CodeSourcery, LLC