From: Mark Kettenis <kettenis@chello.nl>
To: Andrew Cagney <ac131313@ges.redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc,RFA:doco] STORE_RETURN_VALUE with regcache
Date: Tue, 20 Aug 2002 11:22:00 -0000 [thread overview]
Message-ID: <86lm71e6g9.fsf@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: Andrew Cagney's message of "Mon, 19 Aug 2002 20:37:57 -0400"
Andrew Cagney <ac131313@ges.redhat.com> 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
next prev parent reply other threads:[~2002-08-20 18:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-19 17:38 Andrew Cagney
2002-08-20 11:22 ` Mark Kettenis [this message]
2002-08-20 13:01 ` Andrew Cagney
2002-08-22 10:52 ` Andrew Cagney
2002-08-23 5:41 ` Mark Kettenis
2002-08-23 8:53 ` Eli Zaretskii
2002-08-23 17:35 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86lm71e6g9.fsf@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=ac131313@ges.redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox