On Fri, 11 Dec 1998 drochner@zel459.zel.kfa-juelich.de wrote:

> I'm having some problems with the new i386 assembler.
> It doesn't do things the old one did - digest boot
> ROM code in particular.
> This code is a bit hackish because it hand-crafts
> 16-bit code where necessary. The problems seem to
> occur if a 16-bit word is subject of a relocation:
> 	.word	(_start-reloc)
> where "reloc" is a constant which doesn't fit into
> 16 bits (0x80000 in this case). _start is a local
> symbol. (The difference should fit into 16 bit
> because "reloc" is the address where the code finally
> gets linked to.)
[...]
> Well, I can imagine some gross hacks to avoid this,
> but the old assembler could deal with these constructs,
> so I wanted to ask at least.
> 
> Are these bugs or do I expect too much from the
> assembler and/or the relocation data formats?

Hmm... I answered too fast last week. My reasoning was that it looked
odd, but the old assembler handled the source, so it must be OK (and I'm
trying hard to make gas.new bug compatible with the old one.)

The problem is that the old assembler doesn't handle this! It just
silently goes on, generating bogus output. But it is correct for
this case! (and it is too big a bug to be "bug compatible" with... :-)

You can try this by assembling the two following files

   reloc=0x80000
      .text
   kwa:
      .word   0x2323
      .word   kwa-reloc

and

      .text
   kwa:
      .word   0x2323
      .word   kwa-0

and compare the result. They are identical! What is happening is that
the old gas silently truncates 'reloc' to 16 bits.

So rejecting your code is not a bug in gas.new...

   /Krister