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.
As I remember we wanted it and a jump to fit in an exact space at FFF0 or something like that. Ron can tell us better Monday (LANL is closed for a few days because of fire).
well the reason we don't use a symbolic reference to the GDT is that ld kept fouling it up. Hence the need to hardcode the address. I just got disgusted with the whole thing and hand-assembled it.
Unless there is a relocation associated with the instruction (you can see it with `objdump -Sr' on an object file to be sure) ld must not twiddle with the operand. What I wrote above will not create a relocation in any case as the instruction uses absolute addressing and there is no symbol referenced here. If it contained an external symbol reference originally, it will include a relocation but ld should be able to resolve it appropriately in all addressing modes.
If there is a problem with ld it should definitely be reported, otherwise you'll be responsible for the bug remaining forever. There is a mailing list devoted to binutils (i.e. gas, ld, etc.) at binutils@sourceware.cygnus.com. Please also note that many problems with 16-bit code for i386 were fixed during the 2.9.4/2.9.5 development cycle and the 2.10 release should be available really soon. In particular all 16-bit and 8-bit relocations should be handled properly now, so that you may link 16-bit objects together and yield expected results (but you'll often need to write a customized ld script). You should also be able add appropriate operand and address size prefixes automatically using "w" and "l" suffixes and an appropriate format of memory references, now. If you find any instruction that diverges please do not hesitate reporting it.
Maciej