On Sun, Mar 04, 2012 at 08:08:12PM +0000, Julian Pidancet wrote:
On Sun, Mar 4, 2012 at 7:54 PM, Kevin O'Connor kevin@koconnor.net wrote:
The only thing I can think of would be to post-process the assembler and replace "retl" instructions with "retw $2" instructions. I'm not sure if it would work and it would be real ugly.
As I mentionned, ret is not the only instruction causing problems. I've identified issues with leave, enter, iret, and even some forms of the call instruction, and the list is probaly not complete yet. So it could be even more complicated that we think.
It looks like x86emu was never tested with gcc produced code before. And it looks like handling of the 0x66 instruction prefix has been neglected in a lot of different places in the code.
Looking at the current generated code, it would seem that the only problematic instructions actually created by gcc in the current SeaVGABIOS code are "leavel" and "retl". (I don't see "enterl" generated, there are currently no function pointers, and there wont be any 32bit far calls/returns.) I wonder if we could post-process the assembler and replace "retl" with "retw $2" and "leavel" with "movl %ebp, %esp ; popl %ebp". Do you see any issues with that?
-Kevin
On Mon, Mar 5, 2012 at 3:33 PM, Kevin O'Connor kevin@koconnor.net wrote:
Looking at the current generated code, it would seem that the only problematic instructions actually created by gcc in the current SeaVGABIOS code are "leavel" and "retl". (I don't see "enterl" generated, there are currently no function pointers, and there wont be any 32bit far calls/returns.) I wonder if we could post-process the assembler and replace "retl" with "retw $2" and "leavel" with "movl %ebp, %esp ; popl %ebp". Do you see any issues with that?
Well, it is not a very elegant solution, but it seems to be the best plan we have so far.
I can see two problems:
1) If you look at the patch I tried to submit to xorg-devel. Other instructions are concerned, in particular some forms of call (opcode 0xFF). Which means that if we decide to write a postprocess tool, we'll have to check that the ROM doesn't use those instructions.
2) Replacing instructions in the binary is simple, as long as the new instruction is the same size as the replaced instruction.
66 c3 retl (2 bytes) c2 02 00 ret $0x2 (3 bytes)
66 c9 leavel (2 bytes) 66 89 ec mov %ebp,%esp (3 bytes) 66 5d pop %ebp (1 bytes)
Replacing instructions and handling displacement is probably going to be a huge pain.