* [Qemu-devel] [RFC] TCG unit testing
@ 2013-08-23 19:47 Richard Henderson
2013-08-23 20:42 ` Stefan Weil
2013-09-02 16:07 ` Aurelien Jarno
0 siblings, 2 replies; 14+ messages in thread
From: Richard Henderson @ 2013-08-23 19:47 UTC (permalink / raw)
To: qemu-devel; +Cc: Aurelien Jarno
I've been thinking for a while about how to reliably test TCG backends, and
maybe how to do regression testing on them. Having to begin the test from a
guest binary, especially considering the vast cross-compilation problem, is
pretty much a non-starter.
I've been thinking of a truly stripped down target for the purpose, with a
special-purpose machine loop and main to go with it. I.e. avoid vl.c.
My current idea is that the test file consists of 3 sections: guest memory
layout, raw TBs, and expected results. Perhaps best explained with some examples:
(1a) I've split up this test into two TBs to prevent some constant folding.
(1b) The guest machine should have enough registers to make it easy to perform
lots of tests at once. Even better if we can avoid the complication of memory.
--------------------------------------------
# Test basic arithmetic, esp with constant arguments
CODE
0: movi_i32 a0, 0x12345678
movi_i32 a1, 0x87654321
movi_tl pc, 1
exit_tb 0
1: add_i32 a2, a1, a0
sub_i32 a1, a1, a0
movi_i32 t0, 1
add_i32 a3, a0, t0
sub_i32 a4, a0, t0
movi_i32 t0, -1
add_i32 a5, a0, t0
sub_i32 a6, a0, t0
movi_i32 t0, -0x5678
add_i32 a7, a0, t0
sub_i32 a8, a0, t0
movi_i32 t0, 0x123456
add_i32 a9, a0, t0
sub_i32 a10, a0, t0
movi_i32 t0, 0x12341234
add_i32 a11, a0, t0
sub_i32 a12, a0, t0
call done
RESULT
a0 0x12345678
a1 0x7530eca9
a2 0x99999999
a3 0x12345679
a4 0x12345677
a5 0x12345677
a6 0x12345679
a7 0x12340000
a8 0x1234acf0
a9 0x12468ace
a10 0x12222222
a11 0x246868ac
a12 0x4444
-------------------------------------------
(2) The ram layout should be flexible enough to test specific scenarios
-------------------------------------------
# For 64-bit guest, 32-bit host, make sure we compare high-part of tlb
MEM
ram 0x0_0000_0000, 4096
ram 0x1_0000_0000, 4096
CODE
0: movi_i64 b0, 0x12345678abcdef
movi_i64 t1, 0
movi_i64 t2, 0x1_0000_0000
qemu_st32 b0, t1
qemu_ld32 b1, t1
qemu_ld32 b2, t2
call done
RESULT
b0 0x12345678abcdef
b1 0x12345678abcdef
b2 0
-------------------------------------------
(3a) If we let "ioram" be defined via memory_region_init_io, with the "/l" and
"/b" qualifiers controlling the .endianness field of the region, then we can
test the memory access path all the way through.
(3b) The final test in the result section would *not* use the device interface
from memory.h, but rather examine the backing ram directly.
-------------------------------------------
MEM
ioram/l 0, 4096 # little-endian device
ioram/b 4096, 4096 # big-endian device
CODE
0: movi_tl t0, 0x12345678
movi_tl t1, 0
qemu_st32 t0, t1
qemu_ld32 a0, t1
movi_tl t1, 4096
qemu_st32 t0, t1
qemu_ld32 a1, t1
call done
RESULT
a0 0x12345678
a1 0x12345678
mem/b 0, 0x78, 0x56, 0x34, 0x12 # little-endian bytes
mem/b 4096, 0x12, 0x34, 0x56, 0x78 # big-endian bytes
-------------------------------------------
Thoughts? Anything that we ought to be testing that I haven't thought of here,
and that this sort of structure couldn't support?
It may be some time before I can progress this enough to usefulness, but I
wanted to get this written down while it is fresh in my head.
r~
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-08-23 19:47 [Qemu-devel] [RFC] TCG unit testing Richard Henderson
@ 2013-08-23 20:42 ` Stefan Weil
2013-08-23 21:18 ` Richard Henderson
2013-08-27 3:18 ` [Qemu-devel] [RFC] TCG unit testing Lei Li
2013-09-02 16:07 ` Aurelien Jarno
1 sibling, 2 replies; 14+ messages in thread
From: Stefan Weil @ 2013-08-23 20:42 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel, Aurelien Jarno
Am 23.08.2013 21:47, schrieb Richard Henderson:
> I've been thinking for a while about how to reliably test TCG backends, and
> maybe how to do regression testing on them. Having to begin the test from a
> guest binary, especially considering the vast cross-compilation problem, is
> pretty much a non-starter.
>
> I've been thinking of a truly stripped down target for the purpose, with a
> special-purpose machine loop and main to go with it. I.e. avoid vl.c.
>
> My current idea is that the test file consists of 3 sections: guest memory
> layout, raw TBs, and expected results. Perhaps best explained with some examples:
>
> (1a) I've split up this test into two TBs to prevent some constant folding.
> (1b) The guest machine should have enough registers to make it easy to perform
> lots of tests at once. Even better if we can avoid the complication of memory.
>
[...]
> Thoughts? Anything that we ought to be testing that I haven't thought of here,
> and that this sort of structure couldn't support?
>
> It may be some time before I can progress this enough to usefulness, but I
> wanted to get this written down while it is fresh in my head.
>
>
> r~
Since the addition of the TCG interpreter backend, there exist two
backends for each supported host. It is possible to run user code
with well defined instruction order (no asynchronous events like
interrupts) with both backends and to compare the execution
flow. I did that while developing TCI. The process can be reversed:
TCI could be used as reference to test any other backend.
Another approach for testing TCG backends might work like this:
Modifying QEMU so that it is possible to feed the TCG backend
with single TCG opcodes would allow testing some part of the
processing chain:
target opcodes -> tcg opcodes -> host opcodes
<------------------------->
Regards,
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-08-23 20:42 ` Stefan Weil
@ 2013-08-23 21:18 ` Richard Henderson
2013-08-25 17:13 ` Peter Maydell
` (2 more replies)
2013-08-27 3:18 ` [Qemu-devel] [RFC] TCG unit testing Lei Li
1 sibling, 3 replies; 14+ messages in thread
From: Richard Henderson @ 2013-08-23 21:18 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel, Aurelien Jarno
On 08/23/2013 01:42 PM, Stefan Weil wrote:
> Am 23.08.2013 21:47, schrieb Richard Henderson:
>> I've been thinking for a while about how to reliably test TCG backends, and
>> maybe how to do regression testing on them. Having to begin the test from a
>> guest binary, especially considering the vast cross-compilation problem, is
>> pretty much a non-starter.
>>
>> I've been thinking of a truly stripped down target for the purpose, with a
>> special-purpose machine loop and main to go with it. I.e. avoid vl.c.
>>
>> My current idea is that the test file consists of 3 sections: guest memory
>> layout, raw TBs, and expected results. Perhaps best explained with some examples:
>>
>> (1a) I've split up this test into two TBs to prevent some constant folding.
>> (1b) The guest machine should have enough registers to make it easy to perform
>> lots of tests at once. Even better if we can avoid the complication of memory.
>>
> [...]
>> Thoughts? Anything that we ought to be testing that I haven't thought of here,
>> and that this sort of structure couldn't support?
>>
>> It may be some time before I can progress this enough to usefulness, but I
>> wanted to get this written down while it is fresh in my head.
>>
>>
>> r~
>
> Since the addition of the TCG interpreter backend, there exist two
> backends for each supported host. It is possible to run user code
> with well defined instruction order (no asynchronous events like
> interrupts) with both backends and to compare the execution
> flow. I did that while developing TCI. The process can be reversed:
> TCI could be used as reference to test any other backend.
>
> Another approach for testing TCG backends might work like this:
>
> Modifying QEMU so that it is possible to feed the TCG backend
> with single TCG opcodes would allow testing some part of the
> processing chain:
>
> target opcodes -> tcg opcodes -> host opcodes
I don't see how TCI really comes into this except as Yet Another Backend to be
tested. Indeed, such unit testing could show that TCI is in fact broken wrt
helpers, depending on the host abi.
E.g. tci never defines TCG_TARGET_CALL_ALIGN_ARGS. Thus if one uses tci on an
ARM host, a helper like
DEF_HELPER_FLAGS_2(store_fpcr, TCG_CALL_NO_RWG, void, env, i64)
will have its arguments loaded into TCI's R0, R1, R2, and thence into the ARM
r0, r1, r2. But the ARM abi requires the i64 input to be aligned, and thus it
should be r0, r2, r3.
r~
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-08-23 21:18 ` Richard Henderson
@ 2013-08-25 17:13 ` Peter Maydell
2013-08-25 19:45 ` Stefan Weil
2013-09-10 21:34 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Stefan Weil
2 siblings, 0 replies; 14+ messages in thread
From: Peter Maydell @ 2013-08-25 17:13 UTC (permalink / raw)
To: Richard Henderson; +Cc: Stefan Weil, qemu-devel, Aurelien Jarno
On 23 August 2013 22:18, Richard Henderson <rth@twiddle.net> wrote:
> E.g. tci never defines TCG_TARGET_CALL_ALIGN_ARGS. Thus if one uses tci on an
> ARM host, a helper like
>
> DEF_HELPER_FLAGS_2(store_fpcr, TCG_CALL_NO_RWG, void, env, i64)
>
> will have its arguments loaded into TCI's R0, R1, R2, and thence into the ARM
> r0, r1, r2. But the ARM abi requires the i64 input to be aligned, and thus it
> should be r0, r2, r3.
Oh, TCI does that? That's just broken -- you can't treat all helpers the same
that way. You either need to have a bit of per-CPU glue code which knows
how to adjust things to the calling convention (which would defeat the point
of TCI being CPU-independent) or you need to defer to a library that can do
it (libffi would be the obvious choice) or you need to actually have the C
code in the interpreter make the call with all the correct argument types
(should be technically possible for qemu I guess since we have a fixed
set of helper functions and we know the types at compile time, though
it might be kind of painful).
-- PMM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-08-23 21:18 ` Richard Henderson
2013-08-25 17:13 ` Peter Maydell
@ 2013-08-25 19:45 ` Stefan Weil
2013-09-10 21:34 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Stefan Weil
2 siblings, 0 replies; 14+ messages in thread
From: Stefan Weil @ 2013-08-25 19:45 UTC (permalink / raw)
To: Richard Henderson; +Cc: Peter Maydell, qemu-devel, Aurelien Jarno
Am 23.08.2013 23:18, schrieb Richard Henderson:
>
> I don't see how TCI really comes into this except as Yet Another Backend to be
> tested. Indeed, such unit testing could show that TCI is in fact broken wrt
> helpers, depending on the host abi.
TCI is special because it is the only TCG backend which works (more or less)
for all hosts, so it can be improved to be a reference implementation.
Then it will be possible to compare execution traces from TCI with other
TCG backends.
> E.g. tci never defines TCG_TARGET_CALL_ALIGN_ARGS. Thus if one uses tci on an
> ARM host, a helper like
>
> DEF_HELPER_FLAGS_2(store_fpcr, TCG_CALL_NO_RWG, void, env, i64)
>
> will have its arguments loaded into TCI's R0, R1, R2, and thence into the ARM
> r0, r1, r2. But the ARM abi requires the i64 input to be aligned, and thus it
> should be r0, r2, r3.
>
>
> r~
Yes, those possible alignment issues were already discussed earlier.
Up to now, nobody cared enough to fix them. I have run some very
limited tests on ARM hardware. My tests did not trigger those problems.
I don't think that fixing the argument passing to helper functions is
very difficult: we have a limited set of different helper function
prototypes and can generate different calls for each case. This
might even speed up TCI a little bit because only necessary parameters
would be passed instead of the maximum number like it is done today.
This and other known (or unknown) problems of the TCI backend will of
course be fixed as soon as there are TCG unit tests which detect
these problems. :-) That's why I am very interested in such unit tests
and other tests for TCG backends.
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-08-23 20:42 ` Stefan Weil
2013-08-23 21:18 ` Richard Henderson
@ 2013-08-27 3:18 ` Lei Li
1 sibling, 0 replies; 14+ messages in thread
From: Lei Li @ 2013-08-27 3:18 UTC (permalink / raw)
To: Stefan Weil, Richard Henderson; +Cc: qemu-devel, Aurelien Jarno
On 08/24/2013 04:42 AM, Stefan Weil wrote:
> Am 23.08.2013 21:47, schrieb Richard Henderson:
>> I've been thinking for a while about how to reliably test TCG backends, and
>> maybe how to do regression testing on them. Having to begin the test from a
>> guest binary, especially considering the vast cross-compilation problem, is
>> pretty much a non-starter.
>>
>> I've been thinking of a truly stripped down target for the purpose, with a
>> special-purpose machine loop and main to go with it. I.e. avoid vl.c.
>>
>> My current idea is that the test file consists of 3 sections: guest memory
>> layout, raw TBs, and expected results. Perhaps best explained with some examples:
>>
>> (1a) I've split up this test into two TBs to prevent some constant folding.
>> (1b) The guest machine should have enough registers to make it easy to perform
>> lots of tests at once. Even better if we can avoid the complication of memory.
>>
> [...]
>> Thoughts? Anything that we ought to be testing that I haven't thought of here,
>> and that this sort of structure couldn't support?
>>
>> It may be some time before I can progress this enough to usefulness, but I
>> wanted to get this written down while it is fresh in my head.
>>
>>
>> r~
> Since the addition of the TCG interpreter backend, there exist two
> backends for each supported host. It is possible to run user code
> with well defined instruction order (no asynchronous events like
> interrupts) with both backends and to compare the execution
> flow. I did that while developing TCI. The process can be reversed:
> TCI could be used as reference to test any other backend.
>
> Another approach for testing TCG backends might work like this:
>
> Modifying QEMU so that it is possible to feed the TCG backend
> with single TCG opcodes would allow testing some part of the
> processing chain:
>
> target opcodes -> tcg opcodes -> host opcodes
> <------------------------->
Really nice if we could support this!
>
> Regards,
> Stefan
>
>
--
Lei
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-08-23 19:47 [Qemu-devel] [RFC] TCG unit testing Richard Henderson
2013-08-23 20:42 ` Stefan Weil
@ 2013-09-02 16:07 ` Aurelien Jarno
2013-09-07 2:38 ` Rob Landley
1 sibling, 1 reply; 14+ messages in thread
From: Aurelien Jarno @ 2013-09-02 16:07 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel
On Fri, Aug 23, 2013 at 12:47:43PM -0700, Richard Henderson wrote:
> I've been thinking for a while about how to reliably test TCG backends, and
> maybe how to do regression testing on them. Having to begin the test from a
> guest binary, especially considering the vast cross-compilation problem, is
> pretty much a non-starter.
Given the regular breakages we have with TCG, it's really a gread idea.
Usually most of the targets are working correctly so the problem is not
found immediately.
> I've been thinking of a truly stripped down target for the purpose, with a
> special-purpose machine loop and main to go with it. I.e. avoid vl.c.
I think we should use as much as possible of the current infrastructure,
having two different main loops means they are going to be
desynchronised at some point.
Ideally it would be nice to have a machine called TCG (maybe with a few
variants for big/little endian, 32 and 64-bits) which loads TCG "code"
from a text file and execute it. Then we can imagine zillions of small
testcases like the GCC ones, and more can be added when a problem is
discovered and fixed.
> My current idea is that the test file consists of 3 sections: guest memory
> layout, raw TBs, and expected results. Perhaps best explained with some examples:
>
> (1a) I've split up this test into two TBs to prevent some constant folding.
> (1b) The guest machine should have enough registers to make it easy to perform
> lots of tests at once. Even better if we can avoid the complication of memory.
>
> --------------------------------------------
> # Test basic arithmetic, esp with constant arguments
> CODE
> 0: movi_i32 a0, 0x12345678
> movi_i32 a1, 0x87654321
> movi_tl pc, 1
> exit_tb 0
>
> 1: add_i32 a2, a1, a0
> sub_i32 a1, a1, a0
> movi_i32 t0, 1
> add_i32 a3, a0, t0
> sub_i32 a4, a0, t0
> movi_i32 t0, -1
> add_i32 a5, a0, t0
> sub_i32 a6, a0, t0
> movi_i32 t0, -0x5678
> add_i32 a7, a0, t0
> sub_i32 a8, a0, t0
> movi_i32 t0, 0x123456
> add_i32 a9, a0, t0
> sub_i32 a10, a0, t0
> movi_i32 t0, 0x12341234
> add_i32 a11, a0, t0
> sub_i32 a12, a0, t0
> call done
>
> RESULT
> a0 0x12345678
> a1 0x7530eca9
> a2 0x99999999
> a3 0x12345679
> a4 0x12345677
> a5 0x12345677
> a6 0x12345679
> a7 0x12340000
> a8 0x1234acf0
> a9 0x12468ace
> a10 0x12222222
> a11 0x246868ac
> a12 0x4444
> -------------------------------------------
>
> (2) The ram layout should be flexible enough to test specific scenarios
>
> -------------------------------------------
> # For 64-bit guest, 32-bit host, make sure we compare high-part of tlb
> MEM
> ram 0x0_0000_0000, 4096
> ram 0x1_0000_0000, 4096
Maybe we can provide a few helper in the simple TCG machine to create
and remove TLB entries, or to memset the memory. That way each code that
is run can use a different memory mapping.
> CODE
> 0: movi_i64 b0, 0x12345678abcdef
> movi_i64 t1, 0
> movi_i64 t2, 0x1_0000_0000
> qemu_st32 b0, t1
> qemu_ld32 b1, t1
> qemu_ld32 b2, t2
> call done
>
> RESULT
> b0 0x12345678abcdef
> b1 0x12345678abcdef
> b2 0
> -------------------------------------------
>
> (3a) If we let "ioram" be defined via memory_region_init_io, with the "/l" and
> "/b" qualifiers controlling the .endianness field of the region, then we can
> test the memory access path all the way through.
> (3b) The final test in the result section would *not* use the device interface
> from memory.h, but rather examine the backing ram directly.
>
> -------------------------------------------
> MEM
> ioram/l 0, 4096 # little-endian device
> ioram/b 4096, 4096 # big-endian device
> CODE
> 0: movi_tl t0, 0x12345678
> movi_tl t1, 0
> qemu_st32 t0, t1
> qemu_ld32 a0, t1
> movi_tl t1, 4096
> qemu_st32 t0, t1
> qemu_ld32 a1, t1
> call done
> RESULT
> a0 0x12345678
> a1 0x12345678
> mem/b 0, 0x78, 0x56, 0x34, 0x12 # little-endian bytes
> mem/b 4096, 0x12, 0x34, 0x56, 0x78 # big-endian bytes
> -------------------------------------------
>
> Thoughts? Anything that we ought to be testing that I haven't thought of here,
> and that this sort of structure couldn't support?
As said above this kind of structure might be difficult to maintain
while we increase it with a lot more tests.
I think the call to helpers, with variable number of arguments and
types, should be tested. Probably also access to the host memory through
the non-qemu ld/st functions. And maybe the condition ops, especially
with some corner cases with signed/unsigned comparisons.
The problem I also see is the testing of optional ops.
Also what about user mode? At least the memory access is different.
> It may be some time before I can progress this enough to usefulness, but I
> wanted to get this written down while it is fresh in my head.
That would be really great if it can be implemented at some point.
Thanks for working on that.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCG unit testing
2013-09-02 16:07 ` Aurelien Jarno
@ 2013-09-07 2:38 ` Rob Landley
0 siblings, 0 replies; 14+ messages in thread
From: Rob Landley @ 2013-09-07 2:38 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: qemu-devel, Richard Henderson
On 09/02/2013 11:07:03 AM, Aurelien Jarno wrote:
> On Fri, Aug 23, 2013 at 12:47:43PM -0700, Richard Henderson wrote:
> > I've been thinking for a while about how to reliably test TCG
> backends, and
> > maybe how to do regression testing on them. Having to begin the
> test from a
> > guest binary, especially considering the vast cross-compilation
> problem, is
> > pretty much a non-starter.
>
> Given the regular breakages we have with TCG, it's really a gread
> idea.
> Usually most of the targets are working correctly so the problem is
> not
> found immediately.
>
> > I've been thinking of a truly stripped down target for the purpose,
> with a
> > special-purpose machine loop and main to go with it. I.e. avoid
> vl.c.
>
> I think we should use as much as possible of the current
> infrastructure,
> having two different main loops means they are going to be
> desynchronised at some point.
>
> Ideally it would be nice to have a machine called TCG (maybe with a
> few
> variants for big/little endian, 32 and 64-bits) which loads TCG "code"
> from a text file and execute it. Then we can imagine zillions of small
> testcases like the GCC ones, and more can be added when a problem is
> discovered and fixed.
Someday, I'd still like to hook Fabrice's old tinycc front end to tcg
as the code generation backend...
Rob
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing)
2013-08-23 21:18 ` Richard Henderson
2013-08-25 17:13 ` Peter Maydell
2013-08-25 19:45 ` Stefan Weil
@ 2013-09-10 21:34 ` Stefan Weil
2013-09-10 21:52 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args Richard Henderson
2013-09-10 21:57 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Peter Maydell
2 siblings, 2 replies; 14+ messages in thread
From: Stefan Weil @ 2013-09-10 21:34 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel, Aurelien Jarno
Am 23.08.2013 23:18, schrieb Richard Henderson:
> I don't see how TCI really comes into this except as Yet Another Backend to be
> tested. Indeed, such unit testing could show that TCI is in fact broken wrt
> helpers, depending on the host abi.
>
> E.g. tci never defines TCG_TARGET_CALL_ALIGN_ARGS. Thus if one uses tci on an
> ARM host, a helper like
>
> DEF_HELPER_FLAGS_2(store_fpcr, TCG_CALL_NO_RWG, void, env, i64)
>
> will have its arguments loaded into TCI's R0, R1, R2, and thence into the ARM
> r0, r1, r2. But the ARM abi requires the i64 input to be aligned, and thus it
> should be r0, r2, r3.
>
>
> r~
For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
configure.
Cross compilations cannot set that macro automatically (or is there some
way to
do this?), so a configure option is needed if the cross target is unknown.
Should we use this mechanism for all hosts (and move the definitions in
tcg-target.h
to a conditional definition in tcg.h), or should we use it only for TCI?
TCI on ARM works for most architectures when I set
TCG_TARGET_CALL_ALIGN_ARGS.
It only fails for qemu-alpha. The alpha disassembler does not work on 32
bit hosts,
therefore debugging is difficult.
Regards,
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args
2013-09-10 21:34 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Stefan Weil
@ 2013-09-10 21:52 ` Richard Henderson
2013-09-10 22:04 ` Stefan Weil
2013-09-10 21:57 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Peter Maydell
1 sibling, 1 reply; 14+ messages in thread
From: Richard Henderson @ 2013-09-10 21:52 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel, Aurelien Jarno
On 09/10/2013 02:34 PM, Stefan Weil wrote:
> For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
> configure. Cross compilations cannot set that macro automatically
> (or is there some way to do this?)
I can't think of a way that would be reasonable from configure.
> Should we use this mechanism for all hosts (and move the definitions in
> tcg-target.h to a conditional definition in tcg.h), or should we use it only for TCI?
I'd prefer a common solution, but it's something easy to get wrong
if there are multiple ABIs in play, e.g. PPC32.
Perhaps let's start with just TCI.
> The alpha disassembler does not work on 32 bit hosts,
> therefore debugging is difficult.
It works on i386. What's your "not working" test case?
r~
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing)
2013-09-10 21:34 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Stefan Weil
2013-09-10 21:52 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args Richard Henderson
@ 2013-09-10 21:57 ` Peter Maydell
1 sibling, 0 replies; 14+ messages in thread
From: Peter Maydell @ 2013-09-10 21:57 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel, Aurelien Jarno, Richard Henderson
On 10 September 2013 22:34, Stefan Weil <sw@weilnetz.de> wrote:
> For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
> configure.
> Cross compilations cannot set that macro automatically (or is there some
> way to
> do this?), so a configure option is needed if the cross target is unknown.
I think setting TCG_TARGET_CALL_ALIGN_ARGS will
work only by fluke and in some cases. For TCI you need
to either:
* really call each C function by its proper prototype
(probably with something funky to pull this out of our
existing macro definitions of helpers)
* use libffi or some equivalent to get the calling convention
right for you
-- PMM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args
2013-09-10 21:52 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args Richard Henderson
@ 2013-09-10 22:04 ` Stefan Weil
2013-09-10 22:22 ` Peter Maydell
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Weil @ 2013-09-10 22:04 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel, Aurelien Jarno
Am 10.09.2013 23:52, schrieb Richard Henderson:
> On 09/10/2013 02:34 PM, Stefan Weil wrote:
>> For native compilations, TCG_TARGET_CALL_ALIGN_ARGS can be set from
>> configure. Cross compilations cannot set that macro automatically
>> (or is there some way to do this?)
> I can't think of a way that would be reasonable from configure.
>
>> Should we use this mechanism for all hosts (and move the definitions in
>> tcg-target.h to a conditional definition in tcg.h), or should we use it only for TCI?
> I'd prefer a common solution, but it's something easy to get wrong
> if there are multiple ABIs in play, e.g. PPC32.
>
> Perhaps let's start with just TCI.
>
>> The alpha disassembler does not work on 32 bit hosts,
>> therefore debugging is difficult.
> It works on i386. What's your "not working" test case?
>
>
> r~
busybox-static from Debian running on 32 bit Linux:
$ alpha-linux-user/qemu-alpha -d in_asm
/usr/gnemul/qemu-alpha/bin/busybox pwd
host mmap_min_addr=0x10000
Reserved 0x21e000 bytes of guest address space
Relocating guest address space from 0x0000000020000000 to 0x20000000
guest_base 0x0
start end size prot
0000000020000000-0000000020218000 0000000000218000 rwx
0000000040000000-0000000040002000 0000000000002000 ---
0000000040002000-0000000040802000 0000000000800000 rw-
0000000020216000-000000012021e000 0000000100008000 rwx
start_brk 0x0000000000000000
end_code 0x00000001202179bd
start_code 0x0000000120000000
start_data 0x0000000120000000
end_data 0x00000001202179bd
start_stack 0x0000000040801160
brk 0x000000012021dcb0
entry 0x00000001200d3fe0
IN:
0x00000001200d3fe0: stq_c zero,23096(t12)
0x00000001200d3fe4: stq_c zero,23096(t12)
0x00000001200d3fe8: stq_c zero,23096(t12)
0x00000001200d3fec: stq_c zero,23096(t12)
0x00000001200d3ff0: stq_c zero,23096(t12)
0x00000001200d3ff4: stq_c zero,23096(t12)
0x00000001200d3ff8: stq_c zero,23096(t12)
0x00000001200d3ffc: stq_c zero,23096(t12)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args
2013-09-10 22:04 ` Stefan Weil
@ 2013-09-10 22:22 ` Peter Maydell
2013-09-11 5:05 ` Stefan Weil
0 siblings, 1 reply; 14+ messages in thread
From: Peter Maydell @ 2013-09-10 22:22 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel, Aurelien Jarno, Richard Henderson
On 10 September 2013 23:04, Stefan Weil <sw@weilnetz.de> wrote:
> busybox-static from Debian running on 32 bit Linux:
>
> $ alpha-linux-user/qemu-alpha -d in_asm
> /usr/gnemul/qemu-alpha/bin/busybox pwd
> host mmap_min_addr=0x10000
> Reserved 0x21e000 bytes of guest address space
> Relocating guest address space from 0x0000000020000000 to 0x20000000
> guest_base 0x0
> start_code 0x0000000120000000
...that doesn't seem like it would fit in a 32 bit host
address space. Am I misinterpreting the log?
Try a 64 bit host and see if it's better?
-- PMM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args
2013-09-10 22:22 ` Peter Maydell
@ 2013-09-11 5:05 ` Stefan Weil
0 siblings, 0 replies; 14+ messages in thread
From: Stefan Weil @ 2013-09-11 5:05 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel, Aurelien Jarno, Richard Henderson
Am 11.09.2013 00:22, schrieb Peter Maydell:
> On 10 September 2013 23:04, Stefan Weil <sw@weilnetz.de> wrote:
>> busybox-static from Debian running on 32 bit Linux:
>>
>> $ alpha-linux-user/qemu-alpha -d in_asm
>> /usr/gnemul/qemu-alpha/bin/busybox pwd
>> host mmap_min_addr=0x10000
>> Reserved 0x21e000 bytes of guest address space
>> Relocating guest address space from 0x0000000020000000 to 0x20000000
>> guest_base 0x0
>> start_code 0x0000000120000000
> ...that doesn't seem like it would fit in a 32 bit host
> address space. Am I misinterpreting the log?
>
> Try a 64 bit host and see if it's better?
>
> -- PMM
Hi,
it's the alpha start address. QEMU masks it to 32 bit for 32 bit targets.
On 64 bit hosts both disassembler and emulation (with and without TCI) work.
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-09-11 5:05 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-23 19:47 [Qemu-devel] [RFC] TCG unit testing Richard Henderson
2013-08-23 20:42 ` Stefan Weil
2013-08-23 21:18 ` Richard Henderson
2013-08-25 17:13 ` Peter Maydell
2013-08-25 19:45 ` Stefan Weil
2013-09-10 21:34 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Stefan Weil
2013-09-10 21:52 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args Richard Henderson
2013-09-10 22:04 ` Stefan Weil
2013-09-10 22:22 ` Peter Maydell
2013-09-11 5:05 ` Stefan Weil
2013-09-10 21:57 ` [Qemu-devel] [RFC] TCI for ARM and other hosts with aligned args (was: Re: [RFC] TCG unit testing) Peter Maydell
2013-08-27 3:18 ` [Qemu-devel] [RFC] TCG unit testing Lei Li
2013-09-02 16:07 ` Aurelien Jarno
2013-09-07 2:38 ` Rob Landley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.