public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Variadic functions
@ 2010-06-08 16:31 Jonas Bonn
  2010-06-08 22:41 ` Ian Lance Taylor
  0 siblings, 1 reply; 2+ messages in thread
From: Jonas Bonn @ 2010-06-08 16:31 UTC (permalink / raw)
  To: gcc

Hi,
I am forwarding to you a mail that I sent to the uClibc mailing list as
I think it is actually a compiler issue.  Please see below for the
original.  Any tips would be greatly appreciated.
/Jonas

-------- Forwarded Message --------
From: jonas at southpole dot se
To: uclibc@uclibc.org
Subject: Variadic functions
Date: Tue, 08 Jun 2010 09:22:28 +0200

Hi,
I am working on the OPENRISC32 (or32) architecture port of uClibc and
have run into a bit of conundrum that I was hoping someone could help me
understand a bit better.  Please bear with me...

----------

The preconditions:

i) The declaration of xdrproc_t is variadic:

typedef bool_t (*xdrproc_t) (XDR *, void *, ...);

ii) In libc/inet/rpc/xdr.c the functions choices->proc, which of type
xdrproc_t is called:

return (*(choices->proc)) (xdrs, unp, LASTUNSIGNED);

iii) choices->proc may be dereferenced to the function
"xdr_accepted_reply" which is defined in libc/inet/rpc/rpc_prot.c as:

bool_t
xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar) { ... }

-----------

Now, the problem:
i)  As xdr_accepted_reply is not defined as variadic, the function is
compiled to find the parameters in registers r3 and r4.
ii)  As choices->proc is variadic (according to the declaration), the
compiler puts the first parameter in a register and the second on on the
stack.

This, of course, becomes problematic!!!

-----------

Workaround:
i)  By redefining xdr_accepted_reply to be variadic, the compiler makes
the function look for paramter 1 in a register and paramter 2 on the
stack, thus matching what it does for the function call.  Like this...

bool_t
xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar, ...) { ... }

------------

Questions:
i)  Is my compiler broken?  If so, is there somewhere in GCC that
specifically handles register/stack parameter passing for variadic
functions???  (GCC 4.2, patched for or32)
ii)  What is the correct compiler behaviour variadic
declarations/definitions?  Should xdr_accepted_reply not be variadic
since it is used in such a context?  Note that there are several
functions that are cast to xdrproc_t and none of them are defined as
variadic...
iii)  Any advice on how to proceed... I know I need to patch something,
but I'm not sure if it's GCC,binutils, or uClibc.

Thanks for bearing with me on this.  Regards,
Jonas

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Variadic functions
  2010-06-08 16:31 Variadic functions Jonas Bonn
@ 2010-06-08 22:41 ` Ian Lance Taylor
  0 siblings, 0 replies; 2+ messages in thread
From: Ian Lance Taylor @ 2010-06-08 22:41 UTC (permalink / raw)
  To: Jonas Bonn; +Cc: gcc

Jonas Bonn <jonas@southpole.se> writes:

> I am forwarding to you a mail that I sent to the uClibc mailing list as
> I think it is actually a compiler issue.  Please see below for the
> original.  Any tips would be greatly appreciated.

This message would be more appropriate for the mailing list
gcc-help@gcc.gnu.org.  Please take any followups to gcc-help.
Thanks.

> i) The declaration of xdrproc_t is variadic:
>
> typedef bool_t (*xdrproc_t) (XDR *, void *, ...);
>
> ii) In libc/inet/rpc/xdr.c the functions choices->proc, which of type
> xdrproc_t is called:
>
> return (*(choices->proc)) (xdrs, unp, LASTUNSIGNED);
>
> iii) choices->proc may be dereferenced to the function
> "xdr_accepted_reply" which is defined in libc/inet/rpc/rpc_prot.c as:
>
> bool_t
> xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar) { ... }


Casting a function pointer to a different type and then calling it is
undefined behaviour in C/C++.  The standard does not guarantee that
this program will work.


> i)  Is my compiler broken?  If so, is there somewhere in GCC that
> specifically handles register/stack parameter passing for variadic
> functions???  (GCC 4.2, patched for or32)

This problem does not indicate that your program is broken.  Calling
variadic functions is handled specially in the backend.  I am not
familiar with the or32 backend, but that is where the code would be.


> ii)  What is the correct compiler behaviour variadic
> declarations/definitions?  Should xdr_accepted_reply not be variadic
> since it is used in such a context?  Note that there are several
> functions that are cast to xdrproc_t and none of them are defined as
> variadic...

That is broken.  You can not casually cast function pointers to
different types.  You especially can not cast them between variadic
and non-variadic.


> iii)  Any advice on how to proceed... I know I need to patch something,
> but I'm not sure if it's GCC,binutils, or uClibc.

You need to patch the source code.  It sounds like that source code is
in uClibc.

Ian

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-06-08 20:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-08 16:31 Variadic functions Jonas Bonn
2010-06-08 22:41 ` Ian Lance Taylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).