From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22318 invoked by alias); 24 Dec 2005 16:36:18 -0000 Received: (qmail 22311 invoked by uid 22791); 24 Dec 2005 16:36:17 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Dec 2005 16:36:17 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-207-150.inter.net.il [83.130.207.150]) by romy.inter.net.il (MOS 3.7.2-GA) with ESMTP id DFR02137 (AUTH halo1); Sat, 24 Dec 2005 18:36:14 +0200 (IST) Date: Sat, 24 Dec 2005 16:36:00 -0000 Message-Id: From: Eli Zaretskii To: gdb@sourceware.org In-reply-to: <20051224162302.GA11929@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 24 Dec 2005 11:23:02 -0500) Subject: Re: Stepping over longjmp presumably broken for glibc Reply-to: Eli Zaretskii References: <20051222211734.GA13178@nevyn.them.org> <20051223132039.GA24942@nevyn.them.org> <20051223152021.GA26794@nevyn.them.org> <20051223170913.GA28791@nevyn.them.org> <20051224162302.GA11929@nevyn.them.org> 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/msg00194.txt.bz2 > Date: Sat, 24 Dec 2005 11:23:02 -0500 > From: Daniel Jacobowitz > > 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 What about the symbols we use when we look for specific functions, like malloc and fork? I also don't see any significant difference between dependencies on intimate details of the runtime library and the details of the ABI, like function prologue emitted by GCC. We depend on that in lots of places. > Also, as a general principle, I aim to keep the debugger as fully > isolated from the debuggee as possible. I agree in principle, but given that we already depend on that, is there any reason to resist in this single case? 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. > > I think that a solution which does not rely on support from the runtime > being debugged is inherently superior to one which does. If we can find one, and if it is not fragile, then I agree 110%.