From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22332 invoked by alias); 10 Dec 2004 18:01: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 22256 invoked from network); 10 Dec 2004 18:01:03 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 10 Dec 2004 18:01:03 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id 7325F6BE63; Fri, 10 Dec 2004 10:01:02 -0800 (PST) Date: Fri, 10 Dec 2004 19:04:00 -0000 From: Randolph Chung To: gdb-patches@sources.redhat.com Subject: Re: [rfc] dummy calls for hppa64-hpux Message-ID: <20041210180102.GX29171@tausq.org> Reply-To: Randolph Chung References: <20041209050558.GD29171@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209050558.GD29171@tausq.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-12/txt/msg00270.txt.bz2 In reference to a message from Randolph Chung, dated Dec 08: > this patch is not yet ready for inclusion, i'm only posting it for > comments because it's rather unorthodox. ok, here's another unfinished idea..... Dave Anglin suggested an alternative scheme to me that seems more robust. I haven't written the code for it yet, but here's a 50-line comment to explain it. Comments before i try it? :) /* In order to make an interspace call, we need to go through a stub. gcc supplies an appropriate stub called "__gcc_plt_call", however, if an application is compiled with HP compilers then this stub is not available. We used to fallback to "__d_plt_call", however that stub is not entirely useful for us because it doesn't do an interspace return back to the caller. In order to keep the code uniform, we instead don't use either of these stubs, but instead write our own onto the stack. A problem arises since the stack is located in a different space than code, so in order to branch to a stack stub, we will need to do an interspace branch. Previous versions of gdb did this by modifying code at the current pc and doing single-stepping to set the pcsq. Since this is highly undesirable, we use a different scheme: All we really need to do the branch to the stub is a short instruction sequence like this: PA1.1: ldsid (rX),r1 mtsp r1,sr0 be,n (sr0,rX) PA2.0: bve,n (sr0,rX) Instead of writing these sequences ourselves, we can find it in the instruction stream that belongs to the current space. While this seems difficult at first, we are actually guaranteed to find the sequences in several places: - in export stubs for shared libraries - For 32-bit code, in the "noshlibs" routine in the main module - For 64-bit code, in the "$START$" routine in the main module (Note that we can cache the address of these sequences in the objfile's private data.) So, what we do is: - write a stack trampoline - look for a suitable instruction sequence in the current space - point the sequence at the trampoline - set the return address of the trampoline to the current instruction (*) - set the continuing address of the "dummy code" as the sequence. (*) An additional twist is that, in order for us to restore the space register to its starting state, we need the trampoline 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. */ Is this better? :) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/