Variadic functions

[Jonas Bonn]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20100608/a4f8885a/attachment.pgp>