Re: GAS m68k-aout relocation bug ?

[Ian Lance Taylor]

Vincent Rivière <address@hidden> writes:

> > Your test case does not generate a relocation entry when using
> > m68k-elf.
> > ...
> > From the evidence presented, it's not obviously broken, since the
> > relocation is against an absolute symbol value.
> 
> In that case, why no relocation entry is generated when using m68k-elf ?

What I meant is that what really matters is the linker output.  If the
linker output is correct, then the fact that it generates an
unnecessary relocation does not matter.

> > What does this address look like after you link it?
> 
> It is not an address, it is a constant value not intented to be relocated !
> 
> In the bug I am describing, a bogus 16-bit relocation entry is generated. The 
> Atari ST file format only supports 32-bit relocation entries (as 16-bit 
> addresses are not used by m68k).

It's hard for me to evaluate what happens with a patched assembler.
If you are generating a file format which does not support a 16-bit
relocation entry, then it seems to me that you should get an error.

> - If the resulting address is still 16-bit wide, the constant is silently 
> relocated. In my example, the constant is 3. When I load the resulting 
> program, after the bogus-relocation, the constant changes to 0x7f1f (so the 
> value of the constant is invalid, and depends on where the program is located 
> in memory).

OK, that answers the question of whether the linker generates correct
output.  It does not.  That means that this is a real bug.

I would say that it is an assembler bug, as you suggested initially.
However, I don't have any particular suggestions as to where to look
to fix it.  For a BFD_ASSEMBLER gas, the routine fixup_segment() in
gas/write.c should avoid emitting a reloc for a reference to a symbol
which is defined.  I think fixup_segment() is also called for the
m68k-aout target; I don't know why it isn't skipping this reloc.

Ian