On Wednesday 28 September 2005 03:00, you wrote: > > I believe using -fno-stack-protector is correct in this case. > > Note that this is in Makefile.target, which is used to compile 'opcodes' > > for the emulated processor. And propolice interferes with that > > (even if it works, it would slow the emulation by doing its checks > > for every 'instruction') > > > > The rest of the qemu is compiled with propolice. > > Propolice only instruments functions which contain what it thinks look > like strings. (A variety of issues make it a bit more complicated > than being able to say just "strings").
Looking into the generated object file (which qemu parses to extract code fragments for dynamic code generation), propolice only affects some small number of 'opcodes'. The problem with qemu is that the parser can not handle local symbols in the object file, and the static string constants that propolice creates to identify the function name breaks qemu. Incidentally, the same problem also breaks amd64 host. On amd64, gcc creates some 'mmx/sse' instructions for floating point operations, and stores some constants in memory (.LCXX symbols). adding -mfpmath=387 switch to OP_CFLAGS fixes this for i386 and amd64 targets but the sparc target is still broken (have not checked the other targets). To summarize, the reason qemu requires -fno-stack-protector is the parsers inability to handle local symbols in the object file. Adding such support would probably fix qemu for most architectures (regardless of propolice). However, -fno-stack-protector is still useful in OP_CFLAGS, since the code fragments in the file are used in dynamic code generation, and smaller/faster is better. Also, as far as I can tell, there are no strings or string handling in opcode functions themselves. Can
