Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA] sh-tdep.c (sh_use_struct_convention): Restructure and fix
Date: Fri, 10 Oct 2003 07:29:00 -0000	[thread overview]
Message-ID: <20031010072929.GF14344@cygbert.vinschen.de> (raw)
In-Reply-To: <16261.53197.951881.194874@localhost.redhat.com>

On Thu, Oct 09, 2003 at 05:14:53PM -0400, Elena Zannoni wrote:
> Corinna Vinschen writes:
>  > Hi,
>  > 
>  > the below patch straightens out sh_use_struct_convention() so that it
>  > allows a far better readability than before, especially by allowing
>  > a bunch of comments spread out through the code.
>  > 
> 
> I just added a detailed comment. Does that match what you implemented?
> I'd prefer the use of 'aggregate' instead of 'struct' in your comments.

Yes, thanks, I saw the comment.  It's enlightening.  However, the
first sentence seems to be a copy/paste hangover:

    /* Should call_function allocate stack space for a struct return?

And even though I have to admit, that I'm not 100% sure (perhaps
I miss a case) I think the implementation should match at least 99%
of the description. 

The difference between the old and the new code is given by allowing
4 byte structs (erm, aggregates) with more than one element, but a size
of 4 byte for the first element.  This sounds somewhat weird, but that's
exactly the case if the 4 byte agregate is a bitfield or contains a
bitfield.  So the change in this patch solves exactly these bitfields
as return type problem.

>  > Additionally it fixes one bug:  A struct of lenght 4 bytes, which
>  > consists of only a bitfield, is returned in register r0, not on the
>  > stack using the struct convention.  So far, GDB got that wrong.
> 
> Is there a test case that was failing? If not, it should be added. 

Yes, testcases which uncover that problem exist in call-ar-st and
call-rt-st.

Actually the whole change was a result of these testcases.  I saw the
bitfield problem but I found the former one-expression evaluation
very unreadable.  So, first I straightened out the expression, then
I added the bitfield case.

>  > +  if (len != 1 && len != 2 && len != 4 && len != 8)
>  > +    return 1;
>  > +  /* Structs with more than 1 fields use struct convention, if...  */
>  > +  if (nelem != 1)
>  > +    {
>  > +      /* ... they are 1 or 2 bytes in size (e.g. struct of two chars)... */
>  > +      if (len != 4 && len != 8)
> 
> Can you just say len == 1 or len == 2 so that it matches your comment?

Sure.  No problem to change this.

> Wait, this contradicts what the comments I just added say:
> 
> For example, a 2-byte aligned structure with size 2 bytes has the
> same size and alignment as a short int, and will be returned in R0.
> 
> Which is correct?

Both.  An aggregate of size 1 or 2 byte with more than 1 element is not
correctly alligned so it will not be returned in R0.

>  > +      /* ... or, if the struct is 4 or 8 bytes and the first field is
>  > +	 not of size 4 bytes.  Note that this also covers structs with
>  > +	 bitfields. */
>  > +      if (TYPE_LENGTH (TYPE_FIELD_TYPE (type, 0)) != 4)
> 
> I am not sure I understand this one, that's why asked a pointer to a
> test case. It seems to contradict the following, i.e. it should still
> be in registers, or maybe I don't understand the language:
> 
> When an aggregate type is returned in R0 and R1, R0 contains the first
> four bytes of the aggregate, and R1 contains the remainder. If the size
> of the aggregate type is not a multiple of 4 bytes, the aggregate is
> tail-padded up to a multiple of 4 bytes. The value of the padding is
> undefined.

Is my above description better?  The code is identical to the former
implementation except for the 4 byte bitfield case.  That one is now
covered here.

I have not attached a new patch, but I've noted to change "struct" to
"aggregate" in the comments and the
  if (len != 4 && len != 8)
to
  if (len == 1 || len == 2)

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.


  reply	other threads:[~2003-10-10  7:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-04 11:39 Corinna Vinschen
2003-10-04 15:54 ` Andrew Cagney
2003-10-04 17:04   ` Kevin Buettner
2003-10-04 17:35     ` Andrew Cagney
2003-10-04 18:13       ` Kevin Buettner
2003-10-06 16:31         ` Andrew Cagney
2003-10-04 18:08   ` Corinna Vinschen
2003-10-06 15:52     ` Andrew Cagney
2003-10-07 14:52       ` Corinna Vinschen
2003-10-08 17:39         ` Andrew Cagney
2003-10-09 22:51     ` Elena Zannoni
2003-10-11 20:05       ` Andrew Cagney
2003-10-09 22:51 ` Elena Zannoni
2003-10-10  7:29   ` Corinna Vinschen [this message]
2003-10-10 15:01     ` Corinna Vinschen
2003-10-10 16:32       ` Elena Zannoni
2003-10-10 16:59         ` Corinna Vinschen
2003-10-10 17:56           ` Elena Zannoni
2003-10-10 19:14             ` Corinna Vinschen
2003-10-10 16:28     ` Elena Zannoni

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=20031010072929.GF14344@cygbert.vinschen.de \
    --to=vinschen@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