From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11669 invoked by alias); 24 May 2004 17:32:56 -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 11654 invoked from network); 24 May 2004 17:32:55 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 May 2004 17:32:55 -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 i4OHWtGI008335 for ; Mon, 24 May 2004 13:32:55 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4OHWs023228; Mon, 24 May 2004 13:32:54 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0BBB92B9D; Mon, 24 May 2004 13:32:47 -0400 (EDT) Message-ID: <40B231BE.50609@gnu.org> Date: Mon, 24 May 2004 17:32: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> <40AE27AC.6090205@gnu.org> <20040521182138.GN566@tausq.org> In-Reply-To: <20040521182138.GN566@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00159.txt.bz2 >>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 > > > sounds ok; i'm curious about what are the other trampoline cases that we > need to deal with. i found another case on hppa where what needs to > happen doesn't really match what infrun.c is doing (i'll describe it > below), but it'll be good if somehow we can handle these in a sort of > standard way so that h_i_e is actually understandable :) > > the other problem i've seen is when stepping into a shared library call > -- again, this goes through a stub. gdb steps into the stub, but before > it has a chance to skip over the stub, it hits this (since the stub has > no corresponding symbol): That case should be handled by the same skip-trampoline logic (it is just another trampoline). > if (step_over_calls == STEP_OVER_UNDEBUGGABLE > && ecs->stop_func_name == NULL) > { > /* The inferior just stepped into, or returned to, an > undebuggable function (where there is no symbol, not even a > minimal symbol, corresponding to the address where the > inferior stopped). Since we want to skip this kind of code, > we keep going until the inferior returns from this > function. */ > [...] > /* Set a breakpoint at callee's return address (the address > at which the caller will resume). */ > insert_step_resume_breakpoint (get_prev_frame (get_current_frame ()), > ecs); > keep_going (ecs); > return; > } > > if i move this block after the next block (that checks for stub frames > and does SKIP_TRAMPOLINE_CODE () processing) then it works... > > I'm still trying to understand why the checks in h_i_e happen in the > current order.... so i don't know whether this is a problem with h_i_e > or somewhere else... The rationale (if we think it can be called that :-) is lost in the depths of time. Perhaps some unwinders barfed when presented with a function with no function name so it was thought that doing the check first was prudent? Anyway, can the IN_SOLIB_RETURN_TRAMPOLINE be moved up as well (with an additional ecs->stop_func_name != NULL check? Andrew