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.)
The complaint is:

cc   -DSUPPORT_BOOTP -DSUPPORT_DHCP -DSUPPORT_TFTP -I/usr/include 
-I/home/drochn
er/stand/netboot/../libsa -DBOOTROM -DRELOC=0x80000 -nostdinc 
-I/home/drochner/s
tand/netboot -I/mnt/sys -I/home/drochner/stand/lib -I/mnt/sys/lib/libsa 
-D_STAND
ALONE -c -traditional-cpp /home/drochner/stand/lib/crt/rom/start_rom.S
/tmp/cc8YMih8.s: Assembler messages:
/tmp/cc8YMih8.s:152: Error: Value of -524232 too large for field of 2 bytes at 
3
4

This can be worked around by replacing "reloc" by
a local symbol with the same value. I've used
"textstart".
But this helps only a bit, I get a message

/tmp/ccE1GYAR.s: Assembler messages:
/tmp/ccE1GYAR.s:343: Error: Can't emit reloc {- .text-seg symbol "textstart"} @
file address 69.
/tmp/ccE1GYAR.s:343: Fatal error: /tmp/ccE1GYAR.s:343: bad return from 
bfd_insta
ll_relocation

which probably originates from a line:

	.word   (_edata-textstart)

later in the code.

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?

best regards
Matthias