From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20132 invoked by alias); 29 Apr 2009 18:54:54 -0000 Received: (qmail 20123 invoked by uid 22791); 29 Apr 2009 18:54:53 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 18:54:47 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n3TIsc4Z024647; Wed, 29 Apr 2009 20:54:38 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n3TIsb2R013043; Wed, 29 Apr 2009 20:54:37 +0200 (CEST) Date: Wed, 29 Apr 2009 18:57:00 -0000 Message-Id: <200904291854.n3TIsb2R013043@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: gdb@sourceware.org In-reply-to: <83zldzco0p.fsf@gnu.org> (message from Eli Zaretskii on Wed, 29 Apr 2009 21:28:54 +0300) Subject: Re: Debugging a frameless function References: <83zldzco0p.fsf@gnu.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00218.txt.bz2 > Date: Wed, 29 Apr 2009 21:28:54 +0300 > From: Eli Zaretskii > > I'm trying to debug a problem in the DJGPP build of a recent GDB > snapshot, whereby stepping into a function compiled with > "-fomit-frame-pointer" throws an error: > > Cannot access memory at address 0x12 > > I reproduce below the test program and the transcript of a GDB session > where I try to debug this. Any hints or ideas are welcome. TIA > > >From what I see, a call to read_reg in dwarf2_frame_cache, that tries > to read the value of EBP, ends up calling > sentinel_frame_prev_register, and from there eventually > target_fetch_registers is called. But since we are in a frameless > function, EBP holds a variable, not the frame pointer, so the value > fetched by target_fetch_registers is 2, which later causes > dwarf2_frame_this_id to call frame_id_build with the first argument > whose value is 0x16, so the address of the stack in that frame is > bogus. And that is what causes the above error message. Please realise that -fomit-frame-pointer means that there really isn't such a thing as a frame pointer anymore. That should be no problem, since GDB doesn't really need a frame pointer but uses the unwound stack pointer instead. This works fine as long as there is debug information that describes how to do that. The fact that dwarf2_frame_cache calls read_reg for %ebp seems to suggest that the DWARF2 CFI (Call Frame Information) says that the stack pointer has been saved in %ebp (like it would be if the function wasn't "frameless"). Since that obviously isn't where the stack pointer is saved, the compiler must have generated CFI that's wrong. This matches my experience that the debug information generated by GCC on i386 with -fomit-frame-pointer was hopelessly broken. This was years ago though (the early 3.x days IIRC).