From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30274 invoked by alias); 3 Jul 2003 18:36:03 -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 30264 invoked from network); 3 Jul 2003 18:36:00 -0000 Received: from unknown (HELO hydra.ubicom.com) (4.20.168.98) by sources.redhat.com with SMTP; 3 Jul 2003 18:36:00 -0000 Received: FROM fenway.scenix.com BY hydra.ubicom.com ; Thu Jul 03 11:33:58 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 31X7LWXG; Thu, 3 Jul 2003 11:33:56 -0700 Message-ID: <005501c34191$aade61f0$0a02a8c0@scenix.com> Reply-To: "Jafa" From: "Jafa" To: "Andrew Cagney" Cc: Subject: Re: ignore helper no longer works? Date: Thu, 03 Jul 2003 18:36: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/msg00067.txt.bz2 Ok, the solution is obvious now that I am looking at it a different way... When in an epilogue stub search for the return address on the stack, even though the prologue code has indicated that the stub itself did not save the return address. It doesn't matter who called the epilogue stub, just the fact that they did means that they saved the return address in their own prologue. The only issue is that the stack backtrace will show the current function being the epilogue stub and its caller being the real functions caller. Thanks Andrew for your advice - it got me thinking along the right lines. Nick ----- Original Message ----- From: "Jafa" To: "Andrew Cagney" Cc: Sent: Thursday, July 03, 2003 10:25 AM Subject: Re: ignore helper no longer works? 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.