From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15444 invoked by alias); 16 Aug 2002 18:34:46 -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 15424 invoked from network); 16 Aug 2002 18:34:45 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 16 Aug 2002 18:34:45 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7GIXXf07635 for ; Fri, 16 Aug 2002 11:33:33 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 16 Aug 2002 11:33:32 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g7GIXWV17594; Fri, 16 Aug 2002 11:33:32 -0700 (PDT) Date: Fri, 16 Aug 2002 11:34:00 -0000 Subject: Re: [RFC] breakpoints and function prologues... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Andrew Cagney From: Jim Ingham In-Reply-To: <3D5C4FCB.4070005@ges.redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00439.txt.bz2 Not to do a pile-on here, but I agree with the other folks. First off - what benefits do we get from moving "break func" to the beginning of the prologue that should make us in a hurry to do it before all or at least most of the targets & debug formats support it well? People who actually want to see the prologue are probably savvy enough to figure out how to do that (it isn't that hard). Most folks, however, could care less about it. The majority of the responses we got when I explained the varobj bug on the Project Builder Users list were along the lines of "What is a prologue, and why should I care about it". The most satisfactory answer for most of them was "You really shouldn't care"... And as a sorry stabs user, I don't see good unwind info coming down the pike any time soon. Sure, I would love to get our toolchain to emit Dwarf, but there is a lot of work to get there (among other things, until duplicate header information elimination is done no one here is going to pay any attention to Dwarf). In the meantime, we have unacceptable behavior from gdb with no easy way to fix it other than the solution proposed - move the break for line numbers past the prologue. Jim On Thursday, August 15, 2002, at 06:05 PM, Andrew Cagney wrote: >> Most users I have talked to think that setting a break on the "{" at >> the beginning of a function means the same thing as setting a >> breakpoint on the function. But that is not the case. "break >> funcName" is AFTER the prologue, "break file: is >> the true function beginning. > > Don't forget that ``break func'' is is going to change. It's going to > go back to the start of the function! > >> However, suppose the user puts his breakpoint on the "{" beginning a >> function (this is what most folks do when they want to break on a >> function generically, BTW.) Then when the IDE stops, it creates the >> varobjs for the local variables, which naively get their frame >> context from the frame pointer (which because we stopped at the >> beginning of the prologue hasn't been updated yet). Then the user >> steps, and all of the variables fail to evaluate correctly, since >> their frame pointer actually points to the previous frame, and there >> is no such variable in the previous frame... > > That is a bug in gdb. GDB should be using the debug info that lets it > set a breakpoint anywhere in the function. > > enjoy, > Andrew > > > -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer