From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3547 invoked by alias); 10 Jun 2004 22:12:36 -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 3539 invoked from network); 10 Jun 2004 22:12:33 -0000 Received: from unknown (HELO pippin.tausq.org) (64.81.244.94) by sourceware.org with SMTP; 10 Jun 2004 22:12:33 -0000 Received: by pippin.tausq.org (Postfix, from userid 1000) id C4422CD29F; Thu, 10 Jun 2004 15:12:38 -0700 (PDT) Date: Thu, 10 Jun 2004 22:12:00 -0000 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Try to get dummy calls working on hpux again Message-ID: <20040610221238.GJ561@tausq.org> Reply-To: Randolph Chung References: <20040610061234.GF561@tausq.org> <40C8B609.5000704@gnu.org> <20040610202337.GH561@tausq.org> <40C8C7C2.5060100@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C8C7C2.5060100@gnu.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-06/txt/msg00247.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. */ 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 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. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/