Re: [Lightning] How to call varargs functions from lightning in x86_64?

[Paulo César Pereira de Andrade]

Paulo César Pereira de Andrade wrote:
>   Hi,
>
>   The attached patch pass these tests in my testing tool:
>
> http://code.google.com/p/exl/source/browse/trunk/check/lightning/varargs.tst

  Just for the record, the test works correctly in i386, but there
are some known issues I noticed:
o there is no need, and it actually is wrong, to modify _jitl.framesize
  in jit_getarg_*
o it is missing support for leaf functions (should be trivial to add)
o #define JIT_FPR(i)    (_XMM8 + (i)) should be _XMM9, and add the
  proper define.

  Please someone confirm :-), in the meantime, I believe SSEUP probably
is actually only used for complex double and complex float, so, this
patch should be very close to a final one.

  The patch is not final, just for considerations, indentation style
may not match yours, or some of the logic may not match yours also,
so, no problems in adjusting it.

  I will try to extend the test case soon also to check for passed and
received parameters of different types, and including some special
values, i.e. 0x80, 0x8000, etc.

> the test basically does:
> 1.
>   o call sprintf with 10 integer arguments
>   o call sscanf with 10 integer pointer arguments
>   o check that sscanf reads back what sprintf wrote
> 2.
>   o call sprintf with 10 double arguments
>   o call sscanf with 10 double pointer arguments
>   o check that sscanf reads back what sprintf wrote
> 3.
>   o call a jit function with 10 integer arguments
>   o the jit function validates the 10 integer arguments
> 4.
>   o call a jit function with 10 double arguments
>   o the jit function validates the 10 double arguments
> 5.
>   o call a jit function with mixed long,double,long,double...
>     totalling 10 longs and 10 doubles
>   o the jit function validates the arguments
> 6.
>   o call sprintf with 10 times the pattern of "%d %f", and pass
>     10 pairs of longs and doubles
>   o call sscanf and validate the buffer contents
>
>   This works in x86_64, but did not check on i386 yet.
> Very experimental patch, and probably will only work with varargs
> functions for > 8 double arguments, as described in the commit message.
> Still need to check calls to prototyped functions with more than 8
> double arguments, and, if that changes, that it would be required to
> have some hint to jit_prepare, what would not be a bad idea at all,
> as then, it could avoid setting %al for the varargs abi, what it
> does regardless of calling a varargs or not (but that is minimal
> overhead)...
>
>   Please review/comment.
>
>   This has the tricks that should be common to other lightning logic:
> o must call arg_* for every arguments, in left to right order
> o must call  getarg_* for every argument, in left to right order
> o must call jit_prepare before jit_prepare_{f,d} and then may call
>   jit_prepare_{f,d} any times, but before pushing arguments
> If not doing the above, it will not work correctly if generating
> more then one jit function, or nested jit functions.

  Later I will probably ask you again about some kind of bitmap of
used registers, e.g. no need to save/restore %r13,%r14,%r15, etc if
not going to use it. The logic should be, tell it is not used,
otherwise, assume it is used, so it does not affect any existing code,
or code that does not know about it (unless such code does something
weird with stack offsets, but then it would be already broken).

  Also, there should be access to the full register set, but by means
of some kind of "extension". Reasoning is that most times jit should
not be generated by some "linear code" a programmer wrote, but some
more complex logic, that should be able to allocate registers, and
know about side effects. This logic would also want to know JIT_V_NUM,
JIT_R_NUM, etc. And then, in the case of x86_64, there are 2 new
"register classes", that are the six integer arguments and eight
float arguments. Another pseudo class would be special use of the
temporary for integers (%r11 now in my patch, to not clobber argument
passed in %r9) and xmm9 (incorrectly set to xmm8 in my initial patch).

  Sorry for writing too much :-)

Paulo