On Sat, 20 May 2000, Ronald G Minnich wrote:
Hmm, why would you encode lgdt manually? I can't recall gas handling it incorrectly and even if it did it would be gas that would need fixing. AFAIR, the "lgdtl %es:2" instruction yields exactly the same bytes as you emit explicitly above.
including the 0x66?
"lgdt" gives you a default argument size, with no prefix ever. "lgdtw" and "lgdtl" specify an explicit argument size, which implies an argument size override prefix if the chosen arument size disagrees with the current .code16/.code32 mode. It's much like "mov" vs "movw" and "movl" and like all other instructions.
Yes, I know "lgdtl" actually works differently than "lgdtw" as the latter one masks the most significant byte out of GDT's base and always treats it as 0x00 due to the 80286 compatibility (where "sgdt" would store it as 0xff and "lgdt" ignore, due to the lack of address lines, mostly).
anyway I'm more than happy to change this code, but I was having GAS pains :-). I like your fix though.
It's actually quite straightforward once you get it. Version 2.9.1 has plenty of bugs in the 16-bit area, though, so be sure to use at least 2.9.5. Version 2.10 should be out soon.
Seriously, though, don't forget that this code doesn't change after this point as far as I am concerned. The real effort at this point is in the C code.
I just noticed a hand-coded assembly and was curious whether there is really something wrong with binutils here.
But thanks for the tip!
You're welcomed.