From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25270 invoked by alias); 3 Jul 2003 17:27:42 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25249 invoked from network); 3 Jul 2003 17:27:38 -0000 Received: from unknown (HELO hydra.ubicom.com) (4.20.168.98) by sources.redhat.com with SMTP; 3 Jul 2003 17:27:38 -0000 Received: FROM fenway.scenix.com BY hydra.ubicom.com ; Thu Jul 03 10:25:37 2003 -0700 Received: from nkelseyxp (NKELSEY-XP [192.168.1.187]) by fenway.scenix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 31X7LWVP; Thu, 3 Jul 2003 10:25:34 -0700 Message-ID: <001901c34188$1e14e770$0a02a8c0@scenix.com> Reply-To: "Jafa" From: "Jafa" To: "Andrew Cagney" Cc: References: <00db01c3410a$684b0050$0a02a8c0@scenix.com> <3F044768.6090403@redhat.com> Subject: Re: ignore helper no longer works? Date: Thu, 03 Jul 2003 17:27:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2003-07/txt/msg00066.txt.bz2 Hi Andrew, >- When stepping, the need to identify and single step through >trampolines / helpers. I have updated the backtrace code so that if it detects that it is in an epilogue stub then return a frame with no known return address (0) and no known FP (0). I can probably work out the FP of the previous function if need be, but have no hope (without some simulation) of figuring out the return address. Step-over at the end of a fucntion results in gdb running without stopping (and it doesn't call ignore_helper). One way to address this problem would be for gdb to call ignore_helper, and then know not attempt a stack-backtrace. Another solution (ok, crude hack) would be for the tdep to cache the last known PC so that if it steps into a stub then it knows where it came from. >- When stopped, the need to back trace out of a trampoline / helper. I think it is accceptable not being able to do a backtrace if you are in an epilogue helper.... the code now returns that the FP and PC are unknown to abort the backtrace. I am open to ideas (I figure this must be a rare but general problem). If all else fails I will implement the crude hack above because I need to get this working. Thanks Nick ----- Original Message ----- From: "Andrew Cagney" To: "Jafa" Cc: Sent: Thursday, July 03, 2003 8:10 AM Subject: Re: ignore helper no longer works? > 1) Say it is my responsibility to determine the return address anywhere in > code, even if it means writing a whole lot of code in gdb to simulate the > execution of these stubs. > > 2) Fix gdb at a higher level so that it doesn't try to obtain a return > address from a helper function - instead keep stepping (like it gdb used to > do). Sounds like you've got two problems: - When stepping, the need to identify and single step through trampolines / helpers. - When stopped, the need to back trace out of a trampoline / helper. Given a core file, it isn't possible to `step'. Your unwinder is going to need to identify and dig itself out of that hole. Main thing to do is to not lie - from what I understand of your case, given a callee that jumped to a helper, you'll end up displaying: caller Andrew > I can figure out the FP ok (all be it that it is painful without being able > to see the prologue) - the old system only asked for the FP and after > detecting that it was the same frame, kept stepping. > > BTW - I have also noticed that gdb now does not call ignore_helper for any > step-over operations, instead relying on the tdep to supply the return > address for the stub. It think it always used to call ignore_helper and if > it was a helper then it stepped rather that setting a breakpoint as if it > was a function. > > I don't want to be too quick to butcher infrun - I would appreciate your > advice.