From: Michael Snyder <msnyder@redhat.com>
To: Richard.Earnshaw@arm.com
Cc: Richard.Earnshaw@buzzard.freeserve.co.uk,
gdb-patches@sources.redhat.com, rearnsha@arm.com
Subject: Re: ARM PATCH fix extract_return_value and store_return_value
Date: Fri, 24 Jan 2003 19:45:00 -0000 [thread overview]
Message-ID: <3E3197BA.98F40D54@redhat.com> (raw)
In-Reply-To: <200301241111.h0OBBxo13651@pc960.cambridge.arm.com>
Richard Earnshaw wrote:
>
> > > 2002-12-14 Richard Earnshaw <rearnsha@arm.com>
> > >
> > > * arm-tdep.c (convert_from_extended): New argument to hold the
> > > type of floating point result we want to convert to. Make input
> > > argument const. Fix all callers.
> > > (convert_to_extended): Similarly.
> > > (arm_extract_return_value): Now takes a regcache argument. Change
> > > code to use regcache accessor functions. Correctly extract
> > > smaller-than-word results on big-endian machines.
> > > (arm_store_return_value): Now takes a regcache argument. Change
> > > code to use regcache accessor functions. Correctly zero/sign extend
> > > smaller than word results before storing into r0.
> > > (arm_gdbarch_init): Register new-style extract_return_value and
> > > store_return_value functions.
> >
> > Hi Richard,
> >
> > I can report that these
> > changes do fix two fails for big-endian running callfuncs.exp.
> > One of the fails was returning a one-byte struct, the other
> > a two-byte struct. There were no other fails in callfuncs.exp.
>
> Excellent. Thanks for doing the tests.
>
> > As is, they conflict with some of Elena's
> > vector changes, but I've massaged them into closer conformance
> > with a more recent revision. Here's my merged patch (not entirely
> > up to date, but more recent than what appears here).
>
> I installed the patches to the public tree back in December, so these
> conflicts must relate to some internal version you are testing on.
D'oh! You're right, I'm working with sources that we're just now
getting ready to contribute. Well, we'll work out the conflicts then.
Meantime, archaeological evidence indicates that we've covered the
cases that were troubling me before, so I guess we can close this
issue at least until Red Hat contributes the iMWXT port.
Thanks so much for your help on this!
Michael
prev parent reply other threads:[~2003-01-24 19:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-14 6:33 Richard Earnshaw
2003-01-24 3:10 ` Michael Snyder
2003-01-24 11:13 ` Richard Earnshaw
2003-01-24 19:45 ` Michael Snyder [this message]
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=3E3197BA.98F40D54@redhat.com \
--to=msnyder@redhat.com \
--cc=Richard.Earnshaw@arm.com \
--cc=Richard.Earnshaw@buzzard.freeserve.co.uk \
--cc=gdb-patches@sources.redhat.com \
--cc=rearnsha@arm.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