I think the reason: to use only one tool
is clean.
> wrong. I thought I would wait until somebody fixed GAS before I
> looked at this stuff, but there is a problem requiring immediate
> attention. The problem is that there doesn't seem to be any way
> to tell GAS to assemble 16-bit, rather than 32-bit instructions.
However, if the GAS is so buggy while handling 16-bit code
it was not, IMHO, the right moment to do as86->GAS conversion.
> It is _not_ just putting 'w' or 'l' after an instruction. To explain,
> If I assemble code in 16-bit mode:
> mov ax,bx ; Intel
> byte sequence is 0x89, 0xd8
It seems to be correct.
> If I am in 16-bit mode and want to assemble:
> mov eax,ebx ; Intel
> byte sequence is 0x66, 0x89, 0xd8
It also seems to be correct.
> If I am in 32-bit mode and want to assemble:
> mov eax,ebx ; Intel
> byte sequence is 0x89, 0xd8 -- just like the 16-bit mov ax,bx
Does it mean that GAS has problems in 32-bit mode ?
> What has happened is that it looks as though source code was 'tweaked`
> to get the correct binary from GAS. This makes the source-code wrong.
Does this problem appear in all versions of GAS (binutils) or has already
been corrected ?
-- ======================================================================= Andrzej M. Krzysztofowicz ankry@mif.pg.gda.pl phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/