[Qemu-devel] Where is this change coming from?

[Ben Taylor <sol10x86@cox.net>]

Compile environment - Solaris 9/Ultra 10 workstation


this is code generated by a 0.7.2-solaris port of dyngen for i386-softmmu/op.h for the function

case INDEX_op_imulb_AL_T0: {
    extern void op_imulb_AL_T0();
extern char __dot_umul __asm__(".umul");
    memcpy(gen_code_ptr, (void *)((char *)&op_imulb_AL_T0+4), 76);
    *(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16))  & ~0x3fffffff)  | (((((long)(&__dot_umul) + 0) - (long)(gen_code_ptr + 16))>>2)     & 0x3fffffff);
    gen_code_ptr += 76;
}
break;


this is the function generated by the 0.8.0-cvs code

case INDEX_op_imulb_AL_T0: {
    extern void op_imulb_AL_T0();
extern char __dot_umul __asm__(".umul");
    memcpy(gen_code_ptr, (void *)((char *)&op_imulb_AL_T0+4), 76);
    *(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16))  & ~0x3fffffff)  | (((((lo + 0) - (long)(gen_code_ptr + 16))>>2)
  & 0x3fffffff);
    gen_code_ptr += 76;
}
break;

This is the compile sequence for the 0.8.0-cvs with the error message:

gcc -Wall -O2 -g -fno-strict-aliasing -m32 -ffixed-g2 -ffixed-g3 -I. -I.. -I/export/src/qemu/qemu-solaris-9/target-i386 -I/export/src/qemu/qemu-solaris-9 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/export/src/qemu/qemu-solaris-9/fpu -DHAS_AUDIO -I/export/src/qemu/qemu-solaris-9/slirp -c -o translate-op.o /export/src/qemu/qemu-solaris-9/translate-op.c
In file included from /export/src/qemu/qemu-solaris-9/translate-op.c:36:
./op.h: In function `dyngen_code':
./op.h:896: error: `lo' undeclared (first use in this function)
./op.h:896: error: (Each undeclared identifier is reported only once
./op.h:896: error: for each function it appears in.)
./op.h:896: error: syntax error before ';' token
./op.h:904: error: `op_cmpneqsd' undeclared (first use in this function)
./op.h:905: error: `param1' undeclared (first use in this function)
./op.h:906: error: `param2' undeclared (first use in this function)
./op.h:894: warning: unused variable `__dot_umul'


looking carefully between the two generated functions, I see that they are slightly
different.  The first one (0.7.2) compiles cleanly and runs.  The second one (0.8.0-cvs)
does not compiile cleanly, and it appears that the function call has been
left off the line of code.

*(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16))  & ~0x3fffffff)  | (((((long)(&__dot_umul) + 0) - (long)(gen_code_ptr + 16))>>2)     & 0x3fffffff);

 *(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16))  & ~0x3fffffff)  | (((((lo + 0) - (long)(gen_code_ptr + 16))>>2)

The specific difference in the working copy has

(((((long)(&__dot_umul) + 0)

while the compile failling copy has 

(((((lo + 0)

Am I missing something?  There are many cascading errors due to "lo not defined"
in this environment, and I'm not really sure if it's a bug, or some problem in my
environment.

Ideas?

Thanks,

Ben