From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26546 invoked by alias); 11 Jun 2004 16:12:48 -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 26219 invoked from network); 11 Jun 2004 16:12:25 -0000 Received: from unknown (HELO pippin.tausq.org) (64.81.244.94) by sourceware.org with SMTP; 11 Jun 2004 16:12:25 -0000 Received: by pippin.tausq.org (Postfix, from userid 1000) id 33D67CD2CB; Fri, 11 Jun 2004 09:12:24 -0700 (PDT) Date: Fri, 11 Jun 2004 16: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: <20040611161224.GE9466@tausq.org> Reply-To: Randolph Chung References: <20040610061234.GF561@tausq.org> <40C8B609.5000704@gnu.org> <20040610202337.GH561@tausq.org> <40C8C7C2.5060100@gnu.org> <20040610221238.GJ561@tausq.org> <40C9CECF.5040902@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C9CECF.5040902@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/msg00266.txt.bz2 > 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. how about this? + /* On HPUX, functions in the main executable and in libraries can be located + in different spaces. In order for us to be able to select the right + space for the function call, we need to go through an instruction seqeunce + to select the right space for the target function, call it, and then + restore the space on return. + + There are two helper routines that can be used for this task -- if + an application is linked with gcc, it will contain a __gcc_plt_call + helper function. __gcc_plt_call, when passed the entry point of an + import stub, will do the necessary space setting/restoration for the + target function. + + For programs that are compiled/linked with the HP compiler, a similar + function called __d_plt_call exists; __d_plt_call expects a PLABEL instead + of an import stub as an argument. + + To summarize, the call flow is: + current function -> dummy frame -> __gcc_plt_call (import stub) + -> target function + or + current function -> dummy frame -> __d_plt_call (plabel) + -> target function + + In general the "funcaddr" argument passed to push_dummy_code is the actual + entry point of the target function. For __gcc_plt_call, we need to + locate the import stub for the corresponding function. Failing that, + we construct a dummy "import stub" on the stack to pass as an argument. + For __d_plt_call, we similarly synthesize a PLABEL on the stack to + pass to the helper function. + + An additional twist is that, in order for us to restore the space register + to its starting state, we need __gcc_plt_call/__d_plt_call to return + to the instruction where we started the call. However, if we put + the breakpoint there, gdb will complain because it will find two + frames on the stack with the same (sp, pc) (with the dummy frame in + between). Currently, we set the return pointer to (pc - 4) of the + current function. FIXME: This is not an ideal solution; possibly if the + current pc is at the beginning of a page, this will cause a page fault. + Need to understand this better and figure out a better way to fix it. */ > Yes. Probably using the tramp-frame logic. tramp-frame doesn't handle frames that are "functions" (that have a name). I think we should make that an attribute of the tramp-frame (whether having a name is ok or not?) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/