Re: [RFC]: Argument setup for sibcalls

[law at redhat dot com]

In message <200304141853 dot h3EIrXuI018835 at hiauly1 dot hia dot nrc dot ca>, "John David Anglin
" writes:
 >> I haven't looked at Alan's bug report, but using FUNCTION_INCOMING_ARG is
 >> definitely the right thing for sibcalls.
 >
 >This was a private communication.  He was working on some AIX ABI
 >issues.
 >
 >> The whole idea behind argument setup for a sibcall is you overwrite the
 >> incoming arguments for the current function with the arguments for the
 >> sibcall because you're simply going to jump to the sibcall target.  You
 >> don't have outgoing arguments because you don't have an outgoing argument
 >> area.
 >
 >Yes, I agree that you don't have an outgoing argument area.  You do
 >have the incoming argument area of the function plus possibly a set
 >of argument registers to use for a sibcall.  FUNCTION_INCOMING_ARG
 >and FUNCTION_ARG deal with argument registers, so I don't see what
 >this has to do with argument space on the stack.  
Once you exhaust the argument registers, you use any stack space that
was allocated for the current function's incoming arguments. 


 >Simply overwriting the incoming arguments doesn't provide the correct
 >behavior.  This can fail in the PA case when sibcall is to a function
 >with a variable number of arguments (e.g., printf) and you try to pass
 >a float value.  Using FUNCTION_INCOMING_ARG, bypasses the special
 >situations where we pass an argument in both floating and general
 >registers.
Then it seems to me we need some way to handle cases where we need to
pass sibcall arguments in multiple registers.  I believe the check for
! TARGET_PORTABLE_RUNTIME was supposed to catch this for the PA port.

 >The definitions of CUMULATIVE_ARGS, INIT_CUMULATIVE_ARGS and
 >INIT_CUMULATIVE_INCOMING_ARGS could be hacked to allow determination
 >of an incoming argument.  However, before trying to fix the code
 >in function_arg, I wanted to check whether FUNCTION_INCOMING_ARG
 >is being used correctly in this situation.  It still seems to me
 >that the current usage assumes a model of register windows that's
 >not applicable to the PA.
Actually, the originaly implementation of sibcalls was done on the PA!
Of course that was in the 32bit SOM world with has a different ABI than
32bit ELF and 64bit ELF.

jeff