From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15601 invoked by alias); 10 Jan 2008 22:10:46 -0000 Received: (qmail 15589 invoked by uid 22791); 10 Jan 2008 22:10:45 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jan 2008 22:10:28 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id m0AM8bfB025843; Thu, 10 Jan 2008 23:08:37 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id m0AM8aDR023344; Thu, 10 Jan 2008 23:08:37 +0100 (CET) Date: Thu, 10 Jan 2008 22:10:00 -0000 Message-Id: <200801102208.m0AM8aDR023344@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@specifix.com CC: ebotcazou@adacore.com, mark.kettenis@xs4all.nl, brobecker@adacore.com, jimb@codesourcery.com, gdb-patches@sourceware.org In-reply-to: <1200001622.14654.29.camel@localhost.localdomain> (message from Michael Snyder on Thu, 10 Jan 2008 13:47:02 -0800) Subject: Re: [RFC/RFA?] Should break FILE:LINENO skip prologue? References: <20080109151745.GA13181@adacore.com> <200801092140.43362.ebotcazou@adacore.com> <200801101058.m0AAw7HA023877@brahms.sibelius.xs4all.nl> <200801101247.28736.ebotcazou@adacore.com> <1200001622.14654.29.camel@localhost.localdomain> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00252.txt.bz2 > From: Michael Snyder > Date: Thu, 10 Jan 2008 13:47:02 -0800 > > On Thu, 2008-01-10 at 12:47 +0100, Eric Botcazou wrote: > > > If generating the right location information for -O0 is too difficult, > > > perhaps the compiler should make life easier for itself and disable > > > scheduling instructions into the prologue? > > > > What do you call "scheduling instructions into the prologue" exactly? > > I wouldn't speak for Mark, but personally I could imagine, say, > that at -O0 gcc might treat the prologue (whatever we decide > that means) as an atom, and not allow non-prologue instructions > to be shuffled into it. > > The next question would be, are automatic variable initializations > part of that atom? > > I might say that I personally rarely need to debug the "formal" > prologue (that part that would exist in any (framed/frameless) > function independent of automatics initialization), and when I > do, it's as a tools developer, not as an ordinary debugger user. > Therefore I don't mind having to do something "special". > > But the initializations are another story, especially if they > require non-trivial stuff like computations or function calls. > Any user might reasonably want to debug those. So any change > that made it difficult for a user to debug those (say by forcing > him to set a break at the label) would go against the grain > for me. I think that the compiler will actually almost never move non-trivial initializations into the prologue, especially if they involve function calls. The prologue is all about putting the origional function arguments in a safe place, and that needs to be done before you call other functions that might clobber registers. So if you have something like: int foo (int i, double d) { int j = 42; float f = sin(d); ... } the first assignment may be scheduled into the prologue, but the second almost certainly won't. I don't think anybody will actually miss the possibility to break on the first assignment. If we can somehow ascertain ourselves that indeed we can still put a breakpoint on the second assignment and have it break before entering sin(), I think Joels origional diff is actually acceptable.