Re: [Qemu-devel] [PATCH] tci: Detect function argument alignment

[Peter Maydell]

On 14 September 2013 08:18, Stefan Weil <address@hidden> wrote:
> Am 12.09.2013 22:35, schrieb Peter Maydell:
>> You're not a native assembly backend, you can't rely on this
>> to be sufficient. Use libffi or call the target function with
>> the exact correct prototype.

> I had a look on libffi now and don't see how it could solve my problem.
> As far as I could see, libffi must be ported to new architectures, so
> its use would restrict the portability of TCI.

Yes, but it's somebody else's problem to port it, not ours.
I present it mostly as an alternative to doing it the hard way.

> Calling the helper function with the correct prototype seems to be the
> solution with the best portability and would also make TCI a little bit
> faster.
> There is a drawback of that solution: it needs modifications in the TCG
> opcode generation which would no longer be identical to all other TCG
> targets (or I'd have to search the given address of the helper function
> in a lookup table which would cost too much time).

Nobody's running TCI for the performance benefit :-) Use a hash
table, there's one in glib and it won't have much overhead at all for lookups.

> Therefore I'd like to implement that solution as a configure time option:
> either TCI calls helpers with the correct prototype, or it uses the macros
> TCG_TARGET_CALL_ALIGN_ARGS and TCG_TARGET_EXTEND_ARGS.
>
> This means that we still need some way to determine the call alignment
> and whether 32 bit arguments are extended to 64 bit values on 64 bit hosts
> for the solution with unmodified TCG opcode generator. Any test for this
> requires native compilation. Of course I can add the known values for
> the common architectures, so these architectures would not require the
> test.

This is worse -- it means the common cases (where there's probably
an ffi port anyhow) won't take the same code paths as the obscure
architectures which are the cases where you might care about TCI
being portable where QEMU otherwise isn't.

-- PMM