From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25760 invoked by alias); 20 Aug 2002 18:22:27 -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 25654 invoked from network); 20 Aug 2002 18:22:25 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250) by sources.redhat.com with SMTP; 20 Aug 2002 18:22:25 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g7KIMGIZ000341; Tue, 20 Aug 2002 20:22:16 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g7KIMGaJ013013; Tue, 20 Aug 2002 20:22:16 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.5/8.12.5/Submit) id g7KIMEUs013010; Tue, 20 Aug 2002 20:22:14 +0200 (CEST) To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc,RFA:doco] STORE_RETURN_VALUE with regcache References: <3D618F65.3000108@ges.redhat.com> From: Mark Kettenis Date: Tue, 20 Aug 2002 11:22:00 -0000 In-Reply-To: Andrew Cagney's message of "Mon, 19 Aug 2002 20:37:57 -0400" Message-ID: <86lm71e6g9.fsf@elgar.kettenis.dyndns.org> X-SW-Source: 2002-08/txt/msg00603.txt.bz2 Andrew Cagney writes: > Hello, > > The attached patch ``upgrades'' STORE_RETURN_VALUE so that it includes > the register cache in which the value should be stored (it was using the > current global register cache). Looks good to me. However, patches like this one break pure multi-arch targets that are converted to use the non-deprecated variants of these functions if they don't fill in the deprecated function in their gdbarch too. My idea for fixing this is illustrated by the following patch, but perhaps there is a more elegant way to do this? Index: gdbarch.sh =================================================================== RCS file: /cvs/src/src/gdb/gdbarch.sh,v retrieving revision 1.155 diff -u -p -r1.155 gdbarch.sh --- gdbarch.sh 16 Aug 2002 00:27:45 -0000 1.155 +++ gdbarch.sh 20 Aug 2002 18:10:25 -0000 @@ -522,7 +522,7 @@ F:2:INTEGER_TO_ADDRESS:CORE_ADDR:integer # f:2:RETURN_VALUE_ON_STACK:int:return_value_on_stack:struct type *type:type:::generic_return_value_on_stack_not::0 f:2:EXTRACT_RETURN_VALUE:void:extract_return_value:struct type *type, struct regcache *regcache, char *valbuf:type, regcache, valbuf:::legacy_extract_return_value::0 -f:2:DEPRECATED_EXTRACT_RETURN_VALUE:void:deprecated_extract_return_value:struct type *type, char *regbuf, char *valbuf:type, regbuf, valbuf::0:0 +f:2:DEPRECATED_EXTRACT_RETURN_VALUE:void:deprecated_extract_return_value:struct type *type, char *regbuf, char *valbuf:type, regbuf, valbuf::0:0::gdbarch->extract_return_value == 0 && gdbarch->deprecated_extract_return_value == 0 f:2:PUSH_ARGUMENTS:CORE_ADDR:push_arguments:int nargs, struct value **args, CORE_ADDR sp, int struct_return, CORE_ADDR struct_addr:nargs, args, sp, struct_return, struct_addr:::default_push_arguments::0 f:2:PUSH_DUMMY_FRAME:void:push_dummy_frame:void:-:::0 F:2:PUSH_RETURN_ADDRESS:CORE_ADDR:push_return_address:CORE_ADDR pc, CORE_ADDR sp:pc, sp:::0 > It also makes the buffer parameters ``[const] void *'' which is more > like most other architecture methods. I noticed that you have been introducing bfd_byte in several of your recent patches. Why's this better than using char? Mark