From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18425 invoked by alias); 29 Apr 2004 16:02:05 -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 18392 invoked from network); 29 Apr 2004 16:02:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 29 Apr 2004 16:02:04 -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 i3TG24KI010339 for ; Thu, 29 Apr 2004 12:02:04 -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 i3TG23v32497; Thu, 29 Apr 2004 12:02:03 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4D1892B9D; Thu, 29 Apr 2004 12:02:05 -0400 (EDT) Message-ID: <409126FD.3080708@gnu.org> Date: Thu, 29 Apr 2004 16:02: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/hppa] handle setting gp for calling shlib functions References: <20040429062324.GX3965@tausq.org> <40910D4F.1020700@gnu.org> <20040429150704.GZ3965@tausq.org> In-Reply-To: <20040429150704.GZ3965@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00675.txt.bz2 >>>> > static CORE_ADDR >>>> >+hppa32_convert_from_func_ptr_addr (struct gdbarch *gdbarch, >>>> >+ CORE_ADDR addr, >>>> >+ struct target_ops *targ) >>>> >+{ >>>> >+ if (addr & 2) >>>> >+ { >>>> >+ ULONGEST gp; >>>> >+ >>>> >+ addr &= ~3; >>>> >+ >>>> >+ gp = read_memory_unsigned_integer (addr + 4, 4); >>>> >+ write_register (19, gp); >>>> >+ addr = read_memory_unsigned_integer (addr, 4); >>>> >+ } >>>> >+ >>>> >+ return addr; >>>> >+} >>>> >+ >>>> >+static CORE_ADDR >> >>> >>> This should be using TARG methods read memory(2), and should not be >>> writing GP to register 19. > > > First point is understood, but about writing to register -- > > How else can this be handled? i.e. where else in the code path of > call_function_by_hand () will I be able to get ahold of the function > descriptor and set the gp? Unfortunatly not here -> it's called with an exec-target for which writing register values is meaningless. It's also ment to have no side effects :-/ > Unfortunately the func_addr that is passed > into push_dummy_call is already the canonicalized function address, > so i cannot do this as part of e.g. find_global_pointer. For PPC64 I used ABI knowledge to do a code address -> descriptor address reverse lookup. Can you do something similar? You've come across one of GDB's weak points - GDB currently isn't the best when it comes to juggling function descriptors and code addresses. Function pointer parameters, for instance, have a similar problem - PPC64 push-dummy-call finds itself pushing code-address and not the descriptor address and hence messes them up :-( Anyway, a thing-to-do-one day is to pass the function's ``value'' (descriptor and type) to push-dummy-call (there has been talk of doing this before). Another is to clean up what's passed as the parameter list -> again descriptors. Andrew