From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28778 invoked by alias); 21 May 2004 16:00:55 -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 28569 invoked from network); 21 May 2004 16:00:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 21 May 2004 16:00:48 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4LG0lGI022904 for ; Fri, 21 May 2004 12:00:48 -0400 Received: from localhost.redhat.com (dhcp64-184.boston.redhat.com [172.16.64.184]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4LG0k009473; Fri, 21 May 2004 12:00:47 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ED75A2B9D; Fri, 21 May 2004 12:00:44 -0400 (EDT) Message-ID: <40AE27AC.6090205@gnu.org> Date: Fri, 21 May 2004 16:00:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Randolph Chung Cc: gdb@sources.redhat.com Subject: Re: [patch/rfc] How to handle stepping into an unresolved plt entry? References: <20040521064435.GJ566@tausq.org> In-Reply-To: <20040521064435.GJ566@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00149.txt.bz2 > On hppa, I noticed that when I do a "step" over an indirect function > call, gdb does not stop inside the called function. I've traced the > problem down to the following: > > An indirect function call on hppa goes through a stub ($$dyncall). > $$dyncall loads a PLABEL from the PLT and jumps to it. In the case that > the PLT is not yet resolved, we need to do the normal PLT fixup () in > the loader before calling the function. > > What seems to be happening now is that when a "step" happens at the > indirect function call, we step into the $$dyncall stub, and in > infrun.c, we do a SKIP_TRAMPOLINE_CODE. This resolves into a pc that > points at the fixup routine. Next, in handle_inferior_event (), we try > to lookup the file/line information for this target pc; it's not found, > and so gdb just goes ahead and insert a breakpoint at the return address > of the stub (which is in the caller) and then calls keep_going (). > If we do a step on a second invocation of the indirect function call, it > works correctly; SKIP_TRAMPOLINE_CODE resolves to an address that points > to the target function, so the file/line lookup works and we insert a > breakpoint in the right place. Hmm, should gdb put a greater reliance on SKIP_TRAMPOLINE_CODE. Something like a new separate clause: if (we've stepped into a function && we're not stopping in this sort of code && skip trampoline returns something) run to skip trampoline breakpoint, possibly doing a step into function > What is actually supposed to happen in this case? The documentation says: > @findex SKIP_TRAMPOLINE_CODE I think these should be generic attributes of the frame, as you note, there are already too many special cases. Andrew > If the target machine has trampoline code that sits between callers and > the functions being called, then define this macro to return a new PC > that is at the start of the real function. > > But how do you do this if your target address is not yet resolved? The > attached patch gives a workaround for this problem (also needs a small > fix to the target code), but it seems a bit clumsy to me.... it's not > like handle_inferior_event () needs any more special cases... :-( > > Comments? Suggestions?