On Tue, Oct 9, 2012 at 3:28 PM, Richard Henderson <[email protected]> wrote: > On 10/09/2012 06:16 AM, Peter Maydell wrote: >> That is, we could drop CONFIG_USER_GUEST_BASE. Does anybody have >> a practical use case for the --disable-guest-base configuration? > > Nope, because the backends are good at eliminating the overhead > during tcg_target_qemu_prologue if guest_base turns out to be zero.
I had some difficulties getting the same code generated with --enable-guest-base as the one generated with --disable-guest-base, for ARM on x86_64. One has to play with -B 0 and -R, and that was not obvious, while --disable-guest-base was obvious for me :-). Guest ARM, host x86_64. $ ./arm-linux-user/qemu-arm -singlestep -d in_asm,out_asm /work/qemu/Tests/arm/gcc-a9-O3 x IN: 0x00008138: e59fc010 ldr ip, [pc, #16] ; 0x8150 OUT: [size=53] 0x602296c0: mov $0x8150,%ebp 0x602296c5: mov $0x2ac1f9b61000,%rdi 0x602296cf: add %rbp,%rdi 0x602296d2: mov (%rdi),%ebp 0x602296d4: mov %ebp,0x30(%r14) 0x602296d8: jmpq 0x602296dd 0x602296dd: mov $0x813c,%ebp 0x602296e2: mov %ebp,0x3c(%r14) 0x602296e6: mov $0x2ac1f6760281,%rax 0x602296f0: jmpq 0x6226d6b6 Running with -B 0 and playing with -R values until the program succeeds in loading finally produces the same code as when compiling QEMU with --disable-guest-base OUT: [size=41] 0x602281a0: mov $0x8150,%ebp 0x602281a5: mov 0x0(%rbp),%ebp 0x602281a8: mov %ebp,0x30(%r14) 0x602281ac: jmpq 0x602281b1 0x602281b1: mov $0x813c,%ebp 0x602281b6: mov %ebp,0x3c(%r14) 0x602281ba: mov $0x2b9b26096281,%rax 0x602281c4: jmpq 0x6226c1b6 I know the reason why reserved_va was set to the current value (cf 288e65b9eea0c9b3cbe21be46f3e24e4e8b2a090), but I thought it was interesting to point out the above. Laurent
