From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21241 invoked by alias); 26 Dec 2005 05:19:35 -0000 Received: (qmail 21232 invoked by uid 22791); 26 Dec 2005 05:19:34 -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; Mon, 26 Dec 2005 05:19:34 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-86-121.inter.net.il [80.230.86.121]) by romy.inter.net.il (MOS 3.7.2-GA) with ESMTP id DFW40452 (AUTH halo1); Mon, 26 Dec 2005 07:19:29 +0200 (IST) Date: Mon, 26 Dec 2005 05:19:00 -0000 Message-Id: From: Eli Zaretskii To: Jim Blandy CC: gdb@sourceware.org In-reply-to: <8f2776cb0512252006i4b28abe7if0fd67dd8cee6f10@mail.gmail.com> (message from Jim Blandy on Sun, 25 Dec 2005 20:06:42 -0800) 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> <8f2776cb0512252006i4b28abe7if0fd67dd8cee6f10@mail.gmail.com> 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/msg00199.txt.bz2 > Date: Sun, 25 Dec 2005 20:06:42 -0800 > From: Jim Blandy > Cc: gdb@sourceware.org > > On 12/24/05, Eli Zaretskii wrote: > > 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. > > Like fork and malloc, the ABI is a published, documented interface. I > think it's all right to depend on that. It's not that simple, you know: we allow the architecture to specify an arbitrary name for the malloc function. I also remember that we sometimes look for several known names of a function, but I cannot for the moment find it in the sources. I did find proc-events.c, which seems to list all the syscall names on a certain platform. > The details of the function prologues emitted by GCC are not a public > interface, and are, again, a constant source of troubles. How do other debuggers do things for which we need the function prologues? If they also have intimate knowledge of the prologues, then I think it's okay for us as well. My point was that we already depend on all kinds of ad-hoc knowledge of the ABI and the runtime, so adding one more dependency would not hurt too much, although I'd applaud to changes to do that without any such dependencies.