Re: binutils development (was Re: Problems building binutils-000220snapshot)

[Alan Modra <alan at SPRI dot Levels dot UniSA dot Edu dot Au>]

On Tue, 22 Feb 2000, H . J . Lu wrote:

> On Tue, Feb 22, 2000 at 05:02:21PM +1030, Alan Modra wrote:
> > 
> > On Mon, 21 Feb 2000, H . J . Lu wrote:
> > 
> > > Wed Dec 23 08:59:23 1998  Maciej W. Rozycki <macro@ds2.pg.gda.pl>
> > > 
> > >         * elf32-i386.c (elf_howto_table): Fix 8/16-bit relocations.
> > 
> > The 8-bit relocation fix went in ages ago, but the 16-bit is one isn't
> > right, which is why I haven't put it in sourceware.  It's not terribly
> > wrong either, but doesn't fix the problem it's trying to address.
> > 
> > In 16-bit mode, we should be able to link the following without
> > any errors, for any size pad up to just under 64k.
> 
> Why is 64k? It is 16bit relocation. You should be able to go both
> directions.

That's right, in 16-bit mode you should be able to jump from any point in
the 64K address space to any other point.  The three little test files
show that both sourceware and your binutils give errors.  The address
calculations really need to be masked to 16 bits (32-bit relocs are masked
to 32 bits if you happen to be assembling with BFD64, otherwise we'd see
the same problem there too)  I've known about this problem for well over a
year, but noone has complained, so figured it wasn't very important ;-)

> 
> # cat foo.s
> .extern bar
> .global foo
> .code16 
> foo:
> jmp bar 
> # cat bar.s
> .extern foo
> .extern xxx
> .global bar
> .global yyy
> .code16 
> bar:
> jmp foo 
> 
> yyy:
> jmp xxx
> # cat xxx.s
> .extern yyy
> .global xxx
> .code16 
> xxx:
> jmp yyy 
> # cat pad.s
> .space 0x7ff0
> # ld -Ttext 0 -e 0 foo.o pad.o bar.o pad.o xxx.o
> 
> 
> H.J.
>