From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32547 invoked by alias); 24 Aug 2002 21:05:27 -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 32360 invoked from network); 24 Aug 2002 21:05:19 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 24 Aug 2002 21:05:19 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7OL5I728310 for ; Sat, 24 Aug 2002 14:05:18 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 24 Aug 2002 14:05:18 -0700 Received: from Jim-Inghams-Computer.local. (vpn-scv-x3-16.apple.com [17.219.194.16]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g7OL5HV22460; Sat, 24 Aug 2002 14:05:17 -0700 (PDT) Date: Sat, 24 Aug 2002 18:31: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: <3D667F89.8090603@ges.redhat.com> Message-Id: <30A3EC98-B7A5-11D6-BB10-000A277A8808@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00805.txt.bz2 Yes, we could change -break-insert to do this. It would still break when somebody uses the console to set breakpoints from within Project Builder, however. Like with Insight, we try to support the console as well as we can from PB (we don't do as good a job as Insight, but we are working towards it). I guess we could go note the breakpoint set event, delete the breakpoint that was just set IF it was set with file:line, and reset it with the "move me past the prologue" cookie. But this seems a bit of a hack. The other option is to add a "set make-old-gdb-users-unhappy-with-break {on,off}" command, and set that from the IDE when we start up gdb. I'm not real thrilled about this either... Jim On Friday, August 23, 2002, at 11:31 AM, Andrew Cagney wrote: >> On Thursday, August 22, 2002, at 04:34 PM, >> gdb-patches-digest-help@sources.redhat.com wrote: >>> The question is, is there a strong reason to change a behavior >>> that has been consistent for a very long time (even if undocumented). >>> Even if the ability to debug the prologue is un-important for most >>> users, it is important to some, and those users (GCC developers, >>> for instance) may be quite accustomed to the current behavior. >>> I am, for instance... > >> The varobj code will fail with file:line number breakpoint setting on >> the { that starts the function. This is, of course, not a problem >> for command-line gdb users, but varobj IS a part of gdb... Until we >> have the CFI stuff well enough set up that, on landing at the >> beginning of the prologue, the scanner will tell us where the stack >> frame WILL be when it has been set up so we can record this properly, >> this will be a problem. > > Aren't varobj/MI and the CLI separate? varobj/MI could easily request > a prologue adjusted breakpoint without modifying the CLI. > > enjoy, > Andrew > > > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb