From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19535 invoked by alias); 28 Apr 2006 21:54:55 -0000 Received: (qmail 19527 invoked by uid 22791); 28 Apr 2006 21:54:55 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Apr 2006 21:54:52 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 31DEF48CE21; Fri, 28 Apr 2006 17:54:50 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03915-01-9; Fri, 28 Apr 2006 17:54:50 -0400 (EDT) Received: from takamaka.act-europe.fr (s142-179-108-108.bc.hsia.telus.net [142.179.108.108]) by nile.gnat.com (Postfix) with ESMTP id D78A848CC4F; Fri, 28 Apr 2006 17:54:49 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 6B63347E7F; Fri, 28 Apr 2006 14:54:49 -0700 (PDT) Date: Fri, 28 Apr 2006 21:54:00 -0000 From: Joel Brobecker To: Jim Blandy Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA/i386] pb reading insns if breakpoints still inserted Message-ID: <20060428215449.GI930@adacore.com> References: <20060428171154.GP17613@adacore.com> <8f2776cb0604281054y116acfdavc3649dd8198d80d0@mail.gmail.com> <200604281839.k3SIdfsq030892@elgar.sibelius.xs4all.nl> <8f2776cb0604281358x2f667d00s90e03051f034b91c@mail.gmail.com> <200604282109.k3SL9Jwp020317@elgar.sibelius.xs4all.nl> <20060428211258.GA6713@nevyn.them.org> <8f2776cb0604281442m2f514240i9f86b4bfa38b1c33@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0604281442m2f514240i9f86b4bfa38b1c33@mail.gmail.com> User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00378.txt.bz2 > So you guys would like to push the deprecation boundary further the > other way, and deprecate SKIP_PROLOGUE itself? That's an idea. I agree with idea, but in my humble opinion, it's premature. We're still stuck with many platforms that are still in the dark ages and don't provide the necessary frame info in the debugging info for us to be able to correctly locate function arguments, unwind the call stack, etc. > I think the argument was that, in the long run, GCC should be emitting > location lists so that the debugging information accurately describes > the location of the arguments even within the prologues. Setting a > breakpoint on a function would actually set the breakpoint ... at the > function's entry point. We could delete SKIP_PROLOGUE altogether. > Then, there'd be no point in producing or consuming an "end of > prologue" marker whose meaning is kind of vague anyway. I agree, especially at higher levels of optimization, the notion of prologue becomes fuzzier and fuzzier. But not all architectures offer this level of information, and sometimes the system libraries offer nothing at all but the symbol table. -- Joel