From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25371 invoked by alias); 24 Dec 2005 16:59:06 -0000 Received: (qmail 25364 invoked by uid 22791); 24 Dec 2005 16:59:05 -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:59:04 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EqCjT-0003Fl-Np for gdb@sourceware.org; Sat, 24 Dec 2005 11:58:59 -0500 Date: Sat, 24 Dec 2005 16:59:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Stepping over longjmp presumably broken for glibc Message-ID: <20051224165859.GA12433@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> <20051224162302.GA11929@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/msg00195.txt.bz2 On Sat, Dec 24, 2005 at 06:36:17PM +0200, Eli Zaretskii wrote: > > 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? Ah. I think there's a very important difference between the cases I described and these: Malloc, and fork, and function calling, are all public interfaces. They're described by standards. We don't need to know anything about the particular implementation in order to use them. But there's no standard to cover what we need here - jmp_buf's deliberately an opaque type. > 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. I have less of an argument for this one, but I still do think there's a difference. This is a static dependence rather than a dynamic dependence. We can write it down, usually based on published standards documents. That's more true of the functional ABI than it is of the function prologue sequences. Which one of those two mostly works once we get it implemented, and which one is an evolving and recurring pain that we're contemplating entirely new approaches to? :-) And that doesn't even begin to handle debugging non-GCC-generated code. The more implementation-specific knowledge we have, the less robust we are. > If we can find one, and if it is not fragile, then I agree 110%. I think that single-stepping out of longjmp will not be fragile. It may be hard to implement, but it should be straightforward in principle; it's only going to be hard because of the existing mess in infrun.c. Anyway, that's my two cents. I don't have time to actually implement it right now, which is why I wanted to mention it on the mailing list; so that either someone else will look at it, or I will find the message again later when I can do it myself. -- Daniel Jacobowitz CodeSourcery, LLC