makecontext and its arguments

makecontext and its arguments

[Andreas Jaeger]

Implementing makecontext on x86-64 I noticed a problem with passing
its arguments.

The function is defined as:
void makecontext(ucontext_t *ucp, void (*func)(void),
      int argc, ...);

There's no way to determine the type of the arguments.

The Austin Draft (and also our manual) mentions:

    The application shall ensure that the value of argc matches the
    number of integer arguments passed to func; otherwise, the
    behavior is undefined.

The glibc C implementations use va_arg(ap, long) to access the
parameter.  But this won't work for x86-64 with int arguments since
int arguments are not properly sign extented to 64-bit for variable
arguments.  

My question nails down to whether I can safely use va_arg(ap,int) in
the makecontext implementation or not.

Btw. Our testprogram stdlib/tst-setcontext.c uses:

static void
f1 (long a0, long a1, long a2, long a3)

Shouldn't those be ints? 

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: makecontext and its arguments

[Andreas Schwab]

Andreas Jaeger <aj@suse.de> writes:

|> Implementing makecontext on x86-64 I noticed a problem with passing
|> its arguments.
|> 
|> The function is defined as:
|> void makecontext(ucontext_t *ucp, void (*func)(void),
|>       int argc, ...);
|> 
|> There's no way to determine the type of the arguments.
|> 
|> The Austin Draft (and also our manual) mentions:
|> 
|>     The application shall ensure that the value of argc matches the
|>     number of integer arguments passed to func; otherwise, the
|>     behavior is undefined.

IMHO this is a defect in the standard, because "integer" can mean
anything from char to long long and whatever extended integer type might
be defined.  It does not restrict the arguments to type "int".

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Schwab wrote:

> IMHO this is a defect in the standard, because "integer" can mean
> anything from char to long long and whatever extended integer type might
> be defined.  It does not restrict the arguments to type "int".

I tend to agree.  We use long for that reason.  It's the most useful 
interpretation of "integer".

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9Tqz42ijCOnn/RHQRAo4FAKC+X5Ydv1OHFbGaTs0iK7wOvdz9FgCfdo5o
hipE5q3Y9rMzsF7FVmUckb0=
=2QUl
-----END PGP SIGNATURE-----

Re: makecontext and its arguments

[Andreas Jaeger]

Ulrich Drepper <drepper@redhat.com> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andreas Schwab wrote:
>
>> IMHO this is a defect in the standard, because "integer" can mean
>> anything from char to long long and whatever extended integer type might
>> be defined.  It does not restrict the arguments to type "int".
>
> I tend to agree.  We use long for that reason.  It's the most useful
> interpretation of "integer".

That interpretation of long causes problems for x86-64 since ints are
not sign extented when passed in varargs...

So, what can I do?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: makecontext and its arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Jaeger wrote:
> That interpretation of long causes problems for x86-64 since ints are
> not sign extented when passed in varargs...

How about fixing this mistake in the compiler with a function attribute?

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9TrNK2ijCOnn/RHQRAk4NAJ98ogLrfR8pKOord/GYJZQWAZvuuQCfbfS5
0nP8yjzpmKZ9h7l+L+MLwdE=
=HMtV
-----END PGP SIGNATURE-----

Re: makecontext and its arguments

[Andreas Schwab]

Ulrich Drepper <drepper@redhat.com> writes:

|> Andreas Jaeger wrote:
|> > That interpretation of long causes problems for x86-64 since ints are
|> > not sign extented when passed in varargs...
|> 
|> How about fixing this mistake in the compiler with a function attribute?

???  There is no way to find out the right type in va_arg.  Either the
types match, or you get undefined behaviour.  If you pass an int and
retrieve it as a long all bets are off.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 10:15:06PM +0200, Andreas Schwab wrote:
> Ulrich Drepper <drepper@redhat.com> writes:
> 
> |> Andreas Jaeger wrote:
> |> > That interpretation of long causes problems for x86-64 since ints are
> |> > not sign extented when passed in varargs...
> |> 
> |> How about fixing this mistake in the compiler with a function attribute?
> 
> ???  There is no way to find out the right type in va_arg.  Either the
> types match, or you get undefined behaviour.  If you pass an int and
> retrieve it as a long all bets are off.

Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
promote all varargs into DImode when calling vararg functions with
this attribute?

	Jakub

Re: makecontext and its arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Jelinek wrote:
> Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
> promote all varargs into DImode when calling vararg functions with
> this attribute?

Yep, that's what I had in mind.

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9Tt+52ijCOnn/RHQRAuzVAJ0a02Ik4ssGjmw1wbxs57MLse1TlQCfdilQ
3aEvoH080WLyzU9uPk76FT4=
=1BgL
-----END PGP SIGNATURE-----

Re: makecontext and its arguments

[Andreas Schwab]

Jakub Jelinek <jakub@redhat.com> writes:

|> On Mon, Aug 05, 2002 at 10:15:06PM +0200, Andreas Schwab wrote:
|> > Ulrich Drepper <drepper@redhat.com> writes:
|> > 
|> > |> Andreas Jaeger wrote:
|> > |> > That interpretation of long causes problems for x86-64 since ints are
|> > |> > not sign extented when passed in varargs...
|> > |> 
|> > |> How about fixing this mistake in the compiler with a function attribute?
|> > 
|> > ???  There is no way to find out the right type in va_arg.  Either the
|> > types match, or you get undefined behaviour.  If you pass an int and
|> > retrieve it as a long all bets are off.
|> 
|> Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
|> promote all varargs into DImode when calling vararg functions with
|> this attribute?

How do you know whether you are supposed to sign extend or not?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Andreas Schwab]

Jakub Jelinek <jakub@redhat.com> writes:

|> On Mon, Aug 05, 2002 at 10:29:55PM +0200, Andreas Schwab wrote:
|> > |> Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
|> > |> promote all varargs into DImode when calling vararg functions with
|> > |> this attribute?
|> > 
|> > How do you know whether you are supposed to sign extend or not?
|> 
|> If the type of the argument passed to vararg function is signed, you
|> sign extend, otherwise zero extend. That's what all other 64-bit ABIs do.

How does that help in any way?  If you pass an unsigned int to
makecontext it is not supposed to be signed extended, but zero extended
when assigned to long.  There is no way for va_arg to know that.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Schwab wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> |> On Mon, Aug 05, 2002 at 10:29:55PM +0200, Andreas Schwab wrote:
> |> > |> Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
> |> > |> promote all varargs into DImode when calling vararg functions with
> |> > |> this attribute?
> [...]
> How does that help in any way?  If you pass an unsigned int to
> makecontext it is not supposed to be signed extended, but zero extended
> when assigned to long.  There is no way for va_arg to know that.

What part of "function attribute" do you not understand?

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9TuLe2ijCOnn/RHQRApe5AJwJGdaX7pK27m/S4mVfOsSpddmEbwCfRhoo
YoO6iKGLX65f4iTunvp0wg0=
=KecT
-----END PGP SIGNATURE-----

Re: makecontext and its arguments

[Andreas Schwab]

Ulrich Drepper <drepper@redhat.com> writes:

|> Andreas Schwab wrote:
|> > Jakub Jelinek <jakub@redhat.com> writes:
|> > |> On Mon, Aug 05, 2002 at 10:29:55PM +0200, Andreas Schwab wrote:
|> > |> > |> Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
|> > |> > |> promote all varargs into DImode when calling vararg functions with
|> > |> > |> this attribute?
|> > [...]
|> > How does that help in any way?  If you pass an unsigned int to
|> > makecontext it is not supposed to be signed extended, but zero extended
|> > when assigned to long.  There is no way for va_arg to know that.
|> 
|> What part of "function attribute" do you not understand?

The compiler cannot know what type of va_arg call are used inside
makecontext.  And what if you pass a long long where sizeof (long long) >
sizeof (long)?  The whole thing is just ill-defined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Andreas Schwab]

Jakub Jelinek <jakub@redhat.com> writes:

|> On Mon, Aug 05, 2002 at 10:37:25PM +0200, Andreas Schwab wrote:
|> > Jakub Jelinek <jakub@redhat.com> writes:
|> > 
|> > |> On Mon, Aug 05, 2002 at 10:29:55PM +0200, Andreas Schwab wrote:
|> > |> > |> Adding __attribute__((sane_x86_64_varargs)) to makecontext and make gcc
|> > |> > |> promote all varargs into DImode when calling vararg functions with
|> > |> > |> this attribute?
|> > |> > 
|> > |> > How do you know whether you are supposed to sign extend or not?
|> > |> 
|> > |> If the type of the argument passed to vararg function is signed, you
|> > |> sign extend, otherwise zero extend. That's what all other 64-bit ABIs do.
|> > 
|> > How does that help in any way?  If you pass an unsigned int to
|> > makecontext it is not supposed to be signed extended, but zero extended
|> > when assigned to long.  There is no way for va_arg to know that.
|> 
|> ?? va_arg doesn't need to know that. It would always do va_arg(ap, long).
|> For:
|> unsigned int x;
|> int y;
|> extern void __attribute__((sane_x86_64_varargs)) makecontext (ucontext_t *, void (*)(), int, ...);
|> 
|> {
|> ...
|> makecontext (ucp, fun, 2, x, y);
|> }
|> gcc would ensure that x is zero extended and y sign extended
|> before calling it.

To which type?  What if the integer is of type __int128 (TImode)?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Schwab wrote:

> To which type?  What if the integer is of type __int128 (TImode)?

What has this to do with the problem?

gcc today for x86-64 promotes (signed) char and short to int, unsigned 
char and unsigned short to unsigned.  If a vararg function is marked 
with the new attribute (signed) char, short, int are promoted to long, 
and unsigned char, unsigned short, and unsigned are promoted to unsigned 
long.  This is what happens on all other 64-bit machines.  The compiler 
knows about all the types.

Inside the function (makecontext) we know the parameters are 
long/unsigned long.  You don't use the normal var arg macros with int or 
short or whatever.  The implementor knows about the attribute.

All larger types and pointers and float are left alone.  If you pass 
such a value to makecontext you get what you'd get on other platforms: 
garbage.

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9Tuxl2ijCOnn/RHQRAgutAJ9O34hfZIA535QbkRgKN/03H5+nDwCgocaU
wQZDxjBnyViMYCaIdm6n3Nw=
=Q9/Z
-----END PGP SIGNATURE-----

Re: makecontext and its arguments

[Andreas Schwab]

Ulrich Drepper <drepper@redhat.com> writes:

|> Andreas Schwab wrote:
|> 
|> > To which type?  What if the integer is of type __int128 (TImode)?
|> 
|> What has this to do with the problem?

This is the crux of the problem.  makecontext talks about "integer
arguments", and __int128 is an integer type.  So it is obliged to handle
this.

|> All larger types and pointers and float are left alone.  If you pass such
|> a value to makecontext you get what you'd get on other platforms: garbage.

This is not what the specification says.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: makecontext and its arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Schwab wrote:

> This is the crux of the problem.  makecontext talks about "integer
> arguments", and __int128 is an integer type.  So it is obliged to handle
> this.

This is a completely bogus argument.  Every platform could define 
int1024_t or whatever.  These don't count.  At the time the interface 
was introduced only char, short, int, and long were available.  Nothing 
else can be expected to work.  The method described earlier works 
perfectly for this and the proposed attribute has the potential to help 
many more applications which would suffer from this broken calling 
convention.


> This is not what the specification says.

It says so implicitly.  Whatever is not explicitly specified is 
implicitly left undefined.  And undefined means garbage is allowed.  And 
this is what happens on most platforms.

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9T4e22ijCOnn/RHQRAgk6AKCQPwBE1K2tCx9xNYEcVwEV0Jef5QCfT3yp
6q/Bh4sdpvuR/9G7NhjjN6k=
=m6IN
-----END PGP SIGNATURE-----

Re: makecontext and its arguments

[Andreas Schwab]

Ulrich Drepper <drepper@redhat.com> writes:

|> Andreas Schwab wrote:
|> 
|> > This is the crux of the problem.  makecontext talks about "integer
|> > arguments", and __int128 is an integer type.  So it is obliged to handle
|> > this.
|> 
|> This is a completely bogus argument.  Every platform could define
|> int1024_t or whatever.

Yes, that's all I said.

|> These don't count.

Why?  An extended integer type is also an integer type (6.2.5[#4]).

|> At the time the interface was introduced only char, short, int, and
|> long were available.

Irrelevant.  The specification is part of the current POSIX standard, and
the current POSIX standard does define extended integer types (by
reference to the C standard).

|> Nothing else can be expected to work.  The method described earlier
|> works perfectly for this and the proposed attribute has the potential
|> to help many more applications which would suffer from this broken
|> calling convention.

There is no broken calling convention.  You just cannot use va_arg(,long)
to retrieve an argument of type int (7.15.1.1[#2]).

|> > This is not what the specification says.
|> 
|> It says so implicitly.

Chapter and verse, please.

|> Whatever is not explicitly specified is implicitly left undefined.  And
|> undefined means garbage is allowed.  And this is what happens on most
|> platforms.

I agree that the specification of makecontext is defective, but the
closest approximation is to do s/integer/int/, and that makes our
implementation nonconforming.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."