[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] Get tests/tcg building, fix unused variable war

From: Catalin Patulea
Subject: Re: [Qemu-devel] [PATCH] Get tests/tcg building, fix unused variable warning due to wrong extended asm operand, fix the 'test' make target.
Date: Mon, 16 Jul 2012 16:00:10 -0400

On Mon, Jul 16, 2012 at 3:08 PM, Peter Maydell <address@hidden> wrote:
> You need to have the $(LIBS) after the $^.

>>  test_path.o: test_path.c
>> +       $(CC_I386) $(QEMU_INCLUDES) $(GLIB_CFLAGS) $(CFLAGS) $(LDFLAGS) -c 
>> -o $@ $^
> Ditto.
I don't think I meant to put $(LDFLAGS) in there. This is just a
compilation step, after all. I've taken it out, please let me know if
you still have any troubles building.

>> +#include "compiler.h"  // QEMU_PACKED
> checkpatch complains about this //-syntax comment;
> might as well just drop it.

>> -    asm volatile ("fnstenv %0\n" : : "m" (float_env32));
>> +    asm volatile ("fnstenv %0\n" : "=m" (float_env32));
>>      float_env32.fpus &= ~0x7f;
>>      asm volatile ("fldenv %0\n" : : "m" (float_env32));
>>  }
> This doesn't seem to be sufficient for test-i386 to compile
> for me:
> ccache gcc -m32 -I/home/pm215/src/qemu/qemu/slirp -I.
> -I/home/pm215/src/qemu/qemu -I/home/pm215/src/qemu/qemu/fpu -I../..
> -Wall -O2 -g -fno-strict-aliasing  -o test-i386 \
>               ./test-i386.c ./test-i386-code16.S ./test-i386-vm86.S -lm
> ./test-i386.c: Assembler messages:
> ./test-i386.c:1831: Error: expecting lockable instruction after `lock'

> Since 'lock nop' isn't valid we probably need to do this with
> a .byte directive to emit the sequence we require.
I don't understand why gcc would be generating a lock prefix here..

> (this is gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 on x86.)
I'm on gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) and it appears
unreasonably difficult to get 4.6 on my machine. I'll keep trying but
for now I'm shooting blind.

Wei-Ren, what version of gcc are you running? (and had success with?)

>>  #include <stdarg.h>
> The whole way this test works looks pretty foul to me, so yeah, whatever :-)
I agree that this is grotesque - I'm just trying to make the minimal
number of changes to unbreak things so that I can get on with my fprem
life ;-)

reply via email to

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