From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5284 invoked by alias); 16 Aug 2002 01:05:19 -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 5086 invoked from network); 16 Aug 2002 01:05:18 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Aug 2002 01:05:18 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7A6CD3C03; Thu, 15 Aug 2002 21:05:15 -0400 (EDT) Message-ID: <3D5C4FCB.4070005@ges.redhat.com> Date: Thu, 15 Aug 2002 18:05:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Ingham , gdb-patches@sources.redhat.com Subject: Re: [RFC] breakpoints and function prologues... References: <157B023C-B09E-11D6-BDB5-00039379E320@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00400.txt.bz2 > > 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