qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on no


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures
Date: Wed, 10 Apr 2019 20:21:00 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 4/9/19 8:17 PM, Stefan Weil wrote:
> On 09.04.19 22:39, Richard Henderson wrote:
>> On 4/9/19 9:46 AM, Stefan Weil wrote:
>>> * Calling conventions. The current implementation works on many hosts,
>>> but for example not on Sparc. A fix would require simple calling
>>> conventions for all helper functions (for example stack based argument
>>> passing, can this be enforced?), or it needs to know the signature of
>>> each helper function at runtime. I'm afraid that fixing this would
>>> require much work. A runtime test whether calls of helper functions work
>>> correctly could be implemented easily and could abort the program
>>> execution when calls fail to pass the right arguments. Would such a
>>> runtime test help a little bit?
>>
>> In the rewrite of tci that I proposed some years ago,
>> I used libffi for this.
>>
>> Those patches could probably be recovered...
>>
>> https://patchwork.ozlabs.org/patch/348528/
>> https://patchwork.ozlabs.org/patch/348527/
> 
> 
> The first patch is the important one because it adds the signature to
> each helper function. As soon as this information is passed to the
> interpreter, the rest is simple. It should not be necessary to add a new
> dependency on libffi, because there are no foreign calling conventions
> here: all helpers use the C calling convention of the host architecture.

Perhaps the "foreign" in libffi is confusing you.  Its goal *is* the C calling
convention of the host architecture.

> The TCG implementation for Sparc (and other hosts with special calling
> conventions) must also have some minimum information on the signatures
> of the helper functions. It should be possible to use the same
> information for TCI. Maybe your approach ist a general form which could
> be used for any TCG implementation.

We currently capture only enough information to support the TCG native hosts.
If we were to attempt to support, e.g. m68k as a host, then we would have to
expand this.  What I capture for libffi is exact, so it's certainly possible.

But the number of possible function signatures is large.  I forget the simple
math that expresses this well, but doing this the long way suggests 4372 as the
number of combinations (up to 6 arguments of 3 types; 4 return types).

This number is large enough that you cannot just open code all of the possible
calls.  You absolutely have to know something about the host compiler's calling
convention.

I see only 3 possibilities for this:

(1) Use per host ifdefs and/or assembly to DTRT within TCI.
    This admits that TCI requires *some* porting and does
    not automatically run everywhere.
(2) Use an external library that already has said assembly,
    and has already been ported to every interesting processor,
    since it is often done along with the compiler port.
(3) Write a proper TCG backend for each host.

If you see another possibility, please enlighten me.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]