From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23389 invoked by alias); 4 May 2004 14:03:16 -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 23378 invoked from network); 4 May 2004 14:03:15 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 4 May 2004 14:03:15 -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 i44E3EkI002283 for ; Tue, 4 May 2004 10:03:14 -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 i44E3Ev12463; Tue, 4 May 2004 10:03:14 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3C2F62B9D; Tue, 4 May 2004 10:03:15 -0400 (EDT) Message-ID: <4097A2A3.8030807@gnu.org> Date: Tue, 04 May 2004 14:03: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: Andrew Cagney , Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc/hppa] handle setting gp for calling shlib functions References: <20040429062324.GX3965@tausq.org> <40910D4F.1020700@gnu.org> <20040429150704.GZ3965@tausq.org> <409126FD.3080708@gnu.org> <20040429161357.GA3965@tausq.org> <409131F2.5040706@gnu.org> <20040430040417.GC3965@tausq.org> <409261BF.8010605@gnu.org> In-Reply-To: <409261BF.8010605@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00093.txt.bz2 >>> The function/variable is (well was, it appears to have fallen off the >>> >>>> radar for the moment) also wanted for a second reason. When it comes to implementing ABI variants the full function type info is needed. Hence, a ``struct value'' function descriptor (or descriptor pointer / type) are going to eventually be needed anyway. Hence, I think an updated push-dummy-call with the new parameter would be better. >> >> >> >> i can certainly try to look into this, but in lieu of the above (at >> least in the meantime) would it be ok if i stash the func descriptor passed into convert_from_func_ptr_addr into a "cache" in the >> tdep structure, and in push_dummy_call check the passed in funcaddr >> against the cached value? > > > Er, no, we're going to fix it. What happens if the function pointer value, rather than code start address is passed into push dummy call? The entire value should be passed in, but this is a simple step in that direction. Andrew