From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28089 invoked by alias); 29 Apr 2004 14:12:32 -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 28082 invoked from network); 29 Apr 2004 14:12:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 29 Apr 2004 14:12:31 -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 i3TECUKI008192 for ; Thu, 29 Apr 2004 10:12:31 -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 i3TECUv21891; Thu, 29 Apr 2004 10:12:30 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ED7602B9D; Thu, 29 Apr 2004 10:12:31 -0400 (EDT) Message-ID: <40910D4F.1020700@gnu.org> Date: Thu, 29 Apr 2004 14:12: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> In-Reply-To: <20040429062324.GX3965@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00668.txt.bz2 > +#define FIND_GLOBAL_POINTER \ > + (gdbarch_tdep (current_gdbarch)->find_global_pointer) > + Just not this (macro's are bad m'kay :-). The code should instead do something like: struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); ... ... = tdep->find_global_pointer (...); You'll find most architecture functions have that near the start. The function also needs to add gdbarch|tdep|frame parameters and then use them instead of relying on globals such as current_gdbarch (I need to deprecate that)(1). > 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. Andrew PS: The direction is strongly away from global state. Already GDB has instances where two targets and/or architectures exist simultaneously: (1) When handling 32 on 64-bit debugging (e.g., i386 on amd64) both architectures are active. (2) Computing the entry point address, both the executable (un-relocated) and process targets are active.