From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31052 invoked by alias); 11 Jun 2004 17:30:58 -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 31043 invoked from network); 11 Jun 2004 17:30:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Jun 2004 17:30:57 -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 i5BHUvi7008573 for ; Fri, 11 Jun 2004 13:30:57 -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 i5BHUs019776; Fri, 11 Jun 2004 13:30:54 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 88BEF2B9D; Fri, 11 Jun 2004 13:30:47 -0400 (EDT) Message-ID: <40C9EC47.9020304@gnu.org> Date: Fri, 11 Jun 2004 17:30: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> <40C9CECF.5040902@gnu.org> <20040611161224.GE9466@tausq.org> In-Reply-To: <20040611161224.GE9466@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00268.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 Yes, thanks! Suggest wrapping this bit in *NOINDENT* ... *INDENT* so that you're safe from gdb_indent.sh. > + 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. */ with that addition, it's ok to commit. >>> 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?) I was thinking of the case where the stub was pushed onto the stack - that doesn't have a name. Andrew