From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12802 invoked by alias); 11 Jun 2004 15:25:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12789 invoked from network); 11 Jun 2004 15:25:10 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Jun 2004 15:25:10 -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 i5BFPAi7006854 for ; Fri, 11 Jun 2004 11:25:10 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5BFP9008321; Fri, 11 Jun 2004 11:25:10 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 276352B9D; Fri, 11 Jun 2004 11:25:03 -0400 (EDT) Message-ID: <40C9CECF.5040902@gnu.org> Date: Fri, 11 Jun 2004 15:25: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-patches@sources.redhat.com Subject: Re: [patch/rfc] Try to get dummy calls working on hpux again References: <20040610061234.GF561@tausq.org> <40C8B609.5000704@gnu.org> <20040610202337.GH561@tausq.org> <40C8C7C2.5060100@gnu.org> <20040610221238.GJ561@tausq.org> In-Reply-To: <20040610221238.GJ561@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00263.txt.bz2 >>> Sigh (the relevant code will need comments explaining this). Are you >>> absolutely positively certain this is true (for both HP/UX 10.20 / >>> 11.xx)? :-) > > > there is a comment that explains this already; is this not enough? > + /* We set the breakpoint address and r31 to (close to) where the current > + pc is; when __gcc_plt_call returns, it will restore pcsqh to the > + current value based on this. The -4 is needed for frame unwinding > + to work properly -- we need to land in a different function than > + the current function. */ Given all the questions I'm asking, I think you'll want to include more details. Some sort of summary of this thread. > I've only tested on 11.11 so far.... do you mean "can we do something > simplier with another version of HPUX", or "will this also work with > another version of HPUX"? The answer to the latter is probably yes. The > original code that was deleted also did something similar, but in a much > more ugly way in some cases. > > >>> Also that sequence in the call path, the return path, or both? > > > both; but it is done inside of __gcc_plt_call. > > >>> Having the dummy-code containing a non-trivial sequence of instructions >>> opens up the problem of needing to be able to step through them. Issues >>> similar to the grief I've been going through with signal trampolines. > > > well.... > > the current sequence actually is: > current function -> dummy frame -> __gcc_plt_call -> called function Ah! the comments should include this diagram, I think making this clear (and the need to fudge __gcc_plt_call) is what's really needed. > we need to teach gdb that __gcc_plt_call (__d_plt_call) is a stub and > how to unwind through that. i'm thinking about whether this can be done > with the stub unwinder itself or if we need a special unwinder, because > it doesn't follow the same calling conventions as a regular > function/stub. Yes. Probably using the tramp-frame logic. Andrew