From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18802 invoked by alias); 16 Aug 2002 17:02:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18790 invoked from network); 16 Aug 2002 17:02:06 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 16 Aug 2002 17:02:06 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7GGpuU11786; Fri, 16 Aug 2002 11:51:56 -0500 To: Joel Brobecker Cc: Andrew Cagney , Jim Ingham , gdb-patches@sources.redhat.com Subject: Re: [RFC] breakpoints and function prologues... References: <157B023C-B09E-11D6-BDB5-00039379E320@apple.com> <3D5C4FCB.4070005@ges.redhat.com> <20020816021108.GG906@gnat.com> From: Jim Blandy Date: Fri, 16 Aug 2002 10:02:00 -0000 In-Reply-To: <20020816021108.GG906@gnat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00424.txt.bz2 Joel Brobecker writes: > > Don't forget that ``break func'' is is going to change. It's going to > > go back to the start of the function! > > Why this change? This is going to have a negative effect on the > Alpha Tru64 platform, since the first 2 instructions of the prologue > are often optimized out by the linker. If we move "break func" back to > the start of the function, the breakpoint will never be hit even if the > function is entered. If I understand the optimization you're referring to, GDB's prologue policy accomodates that behavior almost by accident. It's basically an entirely separate reason to skip prologues, and I'm not sure it's germane to the broader debate here. Let me make sure I understand what the Tru64 linker is doing. It recognizes that the first two instructions at some function's entry point are unnecessary, and then it ... here is where I get vague. Does it: a) delete those two instructions from the code stream altogether, shifting all subsequent instructions down in memory, b) leave the instructions there, but adjust the value of the linker symbol to point two instructions beyond where it used to, or c) leave the instructions and the linker symbol value unchanged, but tweak certain jumps to that symbol to actually jump two instructions beyond the symbol's value? I assume it's not a), since you wouldn't have a problem in that case. I kind of think that b) and c) are not entirely GDB's problem: after performing that optimization, then the entry point in the debug information is incorrect. Requiring GDB to skip prologues just to accomodate this optimization is not the right design. Prologue skipping is meant to allow GDB to stop the inferior after the frame pointer has been updated, the return address has been saved, and register arguments have been spilled to their stack slots. It exists to support a simplistic assumption elsewhere in GDB: that saved frame pointers, return addresses, and variables live in a single place throughout the function's lifetime. Removing that assumption (e.g., by supporting CFI and location lists) makes prologue analysis unnecessary. But what you're describing here is a rather different situation: the function has multiple entry points, depending on whether (I'm guessing) it's reached via an intra- or inter-load module call. It seems to me there should be a separate gdbarch method to handle that, because its semantics are different.