From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19655 invoked by alias); 29 May 2003 22:22:59 -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 19617 invoked from network); 29 May 2003 22:22:57 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 29 May 2003 22:22:57 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h4TMMnw5000511; Fri, 30 May 2003 00:22:49 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h4TMMnfE000697; Fri, 30 May 2003 00:22:49 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h4TMMmGm000694; Fri, 30 May 2003 00:22:48 +0200 (CEST) Date: Thu, 29 May 2003 22:22:00 -0000 Message-Id: <200305292222.h4TMMmGm000694@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@redhat.com CC: mludvig@suse.cz, gdb@sources.redhat.com In-reply-to: <3ED66564.1020506@redhat.com> (message from Andrew Cagney on Thu, 29 May 2003 15:54:12 -0400) Subject: Re: dwarf-frame.c question References: <3ED381CB.5050207@suse.cz> <200305291544.h4TFi7aL031832@elgar.kettenis.dyndns.org> <3ED66564.1020506@redhat.com> X-SW-Source: 2003-05/txt/msg00406.txt.bz2 Date: Thu, 29 May 2003 15:54:12 -0400 From: Andrew Cagney > Date: Tue, 27 May 2003 17:18:35 +0200 > From: Michal Ludvig > > Hi Mark, > > why do you decrement unwound PC in dwarf_frame_cache() before using it? > > The unwound PC is the return address, i.e. the instruction that will > be executed when the function returns. Yes, the resume address, or the next instruction that will be executed when the frame resumes. frame_address_in_block() also tries to handle this. Indeed. When I noted the problems with frame_address_in_block() before, we more or less agreed that we needed to add properties to our frames instead of making decision based on a frames type. One such a property could whether to decrease the rerturn address or not. > This is the instruction after > the call instruction. The problem is that if the call instruction is > the last instruction of a function, the return address might point to > the next function: > foo: > ... > call abort > > bar: > push %ebp > mov %esp, %ebp > ... > > That's why the GCC unwinder does the same thing. Note that the > decrementing the PC is wrong for "interrupt frames", which is why the > if-statement is there in the code fragment you cite: > > dwarf-frame.c: > 478 /* Unwind the PC. */ > 479 fs->pc = frame_pc_unwind (next_frame); > 480 if (get_frame_type (next_frame) == NORMAL_FRAME > 481 && frame_relative_level (next_frame) >= 0) > 482 fs->pc--; First an FYI. CFI has that return-address column. I'm left wondering if frame_pc_unwind() should try the frame for the unwound pc before trying for registers. However, there has so far been zero evidence supporting this need so I think, until there is, let it be. It also wouldn't help with this case - it to would still point back to beyond the function :-( I'm not sure what you mean here, but dwarf-frame.c treats the return-address column as the saved/unwound pc. Second, another FYI. This isn't just a CFI problem. There have been earlier posts about how GDB, already gets confused by this - printing out the wrong function address for instance. This problem is generic. Yes indeed it is. Anyway, is it safe to always decrement the resume address before looking for the CFI info? Given a more complex sequence like: 1: setup call 2: call xxx with lots of side effects 3: delay slot saved r0++ 4: discard call then the CFI info for 4 could be very different to that for 2/3. Well, the GCC unwinder seems to think it is safe to do this. Note that we only use the decremented resume address to find the FDE, and that we use the real return address for calculating the CFI. This means that as long as the compiler doesn't store the CFI for 3 and 4 in different FDE's, we'll always have the correct CFI. > Andrew, it seems that we should tweak the frame code > to make sure that frame_unwind_by_pc is always passed a PC *within* the > function. True, but how? It would effectively be frame_unwind_address_in_block() but how reliably/where could it be used? Oops, I meant frame_unwind_find_by_pc instead of frame_unwind_by_pc. Anyway, every invocation of get_frame_pc() is a potential candidate. It seems to me that this deserves a bit more thought. Should I postpone moving the CFI unwinder over to mainline until this is resolved? Alternatively I can comment out the bit of code that decrements the return-address. That would be "acceptable" since the bug it tries to solve is present in the current code too. Mark