From: Andrew Cagney <cagney@gnu.org>
To: Randolph Chung <randolph@tausq.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfa] fix call-dummies for hppa
Date: Wed, 28 Apr 2004 15:42:00 -0000 [thread overview]
Message-ID: <408FD0E7.3000300@gnu.org> (raw)
In-Reply-To: <20040424190231.GC2923@tausq.org>
> This fixes a few bugs in the 32-bit version of the hppa push_dummy_call
> method.
>
> Tested against hppa2.0w-hp-hpux11.11 and hppa-linux.
Which compilers? I'm suspicious of GCC - it too often gets struct
parameters and return values internally consistent but wrong :-(
> All of structs.exp pass, there are still some failures in call-sc.exp
> and callfuncs.exp. In the latter case it appears most are due to
> problems with calling malloc() in the inferior (at least on hppa-linux).
> We simply allocate the appropriate amount of stack space and put
> arguments into their proper slots. */
> -
> +
Be careful of white space change, this shouldn't be included. If you
want to fix some indention just do it separatly.
> CORE_ADDR
> hppa32_push_dummy_call (struct gdbarch *gdbarch, CORE_ADDR func_addr,
> struct regcache *regcache, CORE_ADDR bp_addr,
> int nargs, struct value **args, CORE_ADDR sp,
> int struct_return, CORE_ADDR struct_addr)
> {
> - /* NOTE: cagney/2004-02-27: This is a guess - its implemented by
> - reverse engineering testsuite failures. */
> -
(I've now got a copy of the 32-bit ABI but it doesn't help much)
> /* Stack base address at which any pass-by-reference parameters are
> stored. */
> CORE_ADDR struct_end = 0;
> @@ -781,12 +779,15 @@ hppa32_push_dummy_call (struct gdbarch *
> /* Two passes. First pass computes the location of everything,
> second pass writes the bytes out. */
> int write_pass;
> +
> for (write_pass = 0; write_pass < 2; write_pass++)
> {
> CORE_ADDR struct_ptr = 0;
> - CORE_ADDR param_ptr = 0;
> - int reg = 27; /* NOTE: Registers go down. */
the comment doesn't match the assignment.
> + /* The first parameter goes into sp-36, each stack slot is 4-bytes. */
> + CORE_ADDR param_ptr = 32;
> int i;
> + int small_struct = 0;
> +
> for (i = 0; i < nargs; i++)
> {
> struct value *arg = args[i];
> @@ -795,6 +796,7 @@ hppa32_push_dummy_call (struct gdbarch *
> stack, and [possibly] passed in a register. */
> char param_val[8];
> int param_len;
> +
> memset (param_val, 0, sizeof param_val);
> if (TYPE_LENGTH (type) > 8)
> {
> @@ -813,27 +815,76 @@ hppa32_push_dummy_call (struct gdbarch *
> /* Integer value store, right aligned. "unpack_long"
> takes care of any sign-extension problems. */
> param_len = align_up (TYPE_LENGTH (type), 4);
> +
white space
> store_unsigned_integer (param_val, param_len,
> unpack_long (type,
> VALUE_CONTENTS (arg)));
> }
> + else if (TYPE_CODE (type) == TYPE_CODE_FLT)
> + {
more comments (the rest is well commented), ``&& TYPE_LENGTH () == 4''
test needed?
> + param_len = align_up (TYPE_LENGTH (type), 4);
> + memcpy (param_val, VALUE_CONTENTS (arg), param_len);
> + }
> else
> {
> - /* Small struct value, store right aligned? */
> param_len = align_up (TYPE_LENGTH (type), 4);
> +
> + /* Small struct value are stored right-aligned. */
> memcpy (param_val + param_len - TYPE_LENGTH (type),
> VALUE_CONTENTS (arg), TYPE_LENGTH (type));
> +
> + /* Structures of size 5, 6 and 7 bytes are special in that
> + the higher-ordered word is stored in the lower-ordered
> + argument, and even though it is a 8-byte quantity the
> + registers need not be 8-byte aligned. */
> + if (param_len > 4)
> + small_struct = 1;
> }
> +
> param_ptr += param_len;
> - reg -= param_len / 4;
> + if (param_len == 8 && !small_struct)
> + param_ptr += (param_ptr & 4);
align_up?
Otherwize, yep, thanks for fixing this.
Andrew
next prev parent reply other threads:[~2004-04-28 15:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-24 19:02 Randolph Chung
2004-04-28 15:42 ` Andrew Cagney [this message]
2004-04-28 15:58 ` Randolph Chung
2004-04-28 20:30 ` Andrew Cagney
2004-04-28 17:18 ` Randolph Chung
2004-04-29 0:15 ` Joel Brobecker
2004-04-29 2:59 ` Randolph Chung
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=408FD0E7.3000300@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=randolph@tausq.org \
/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