This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfa] fix call-dummies for hppa
- From: Randolph Chung <randolph at tausq dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 28 Apr 2004 08:58:03 -0700
- Subject: Re: [patch/rfa] fix call-dummies for hppa
- References: <20040424190231.GC2923@tausq.org> <408FD0E7.3000300@gnu.org>
- Reply-to: Randolph Chung <randolph at tausq dot org>
> Which compilers? I'm suspicious of GCC - it too often gets struct
> parameters and return values internally consistent but wrong :-(
gcc only; I don't have access to the hp compilers. However, Dave
(the hppa gcc maintainer) is quite careful about these things, so I
think they are correct ;-)
> Be careful of white space change, this shouldn't be included. If you
> want to fix some indention just do it separatly.
ok, there were some stray tabs in the file so i was cleaning them up
along the way, but i'll remove that from this diff.
> (I've now got a copy of the 32-bit ABI but it doesn't help much)
this is the som runtime doc? it's not particularly clear about small
structs.....
> 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;
it does, actually, because the param_ptr is incremented by 4 for each
argument, so the first one goes to 36.
> >+ 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);
yes, this bit is wrong. i found some more bugs in this function. will
send a new version with the whitespace changes removed and comments
added.
thanks,
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/