Re: [SeaBIOS] vgabios testing

[Kevin O'Connor]

On Mon, Mar 05, 2012 at 04:05:11PM +0000, Julian Pidancet wrote:
> On Mon, Mar 5, 2012 at 3:33 PM, Kevin O'Connor  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:
> 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.

Agreed.  If it's just "calll *%ereg" then it can probably just be
replaced with "pushw $0 ; callw *%reg".
> 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.

I don't think that will be an issue.  One can tell gcc to generate
assembler and then post-process that.  The gcc created assembler is
still label based so no positional issues should arise.

-Kevin

vgabios testing

[Julian Pidancet]

On Mon, Mar 5, 2012 at 4:21 PM, Kevin O'Connor  wrote:
> On Mon, Mar 05, 2012 at 04:05:11PM +0000, Julian Pidancet wrote:
> > 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:
> > 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.
>
> Agreed.  If it's just "calll *%ereg" then it can probably just be
> replaced with "pushw $0 ; callw *%reg".

These forms of the call instruction must also be taken care of:

66 ff 16 34 12          calll  *0x1234
2e 66 ff 16 34 12       calll  *%cs:0x1234
> > 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.
>
> I don't think that will be an issue.  One can tell gcc to generate
> assembler and then post-process that.  The gcc created assembler is
> still label based so no positional issues should arise.

Yes you're right. Post-processing the intermediate assembly will
definitely be a huge win.