[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GAS m68k-aout relocation bug ?
From: |
Vincent Rivière |
Subject: |
Re: GAS m68k-aout relocation bug ? |
Date: |
Mon, 17 Nov 2003 09:27:38 +0100 |
Ian,
Thank you for your quick answer.
> > I'm using GAS 2.14 m68k-aout.
>
> Before we consider anything else, why are you using m68k-aout? The
> a.out format is very obsolete. If you have any flexibility here, I
> strongly recommend using m68k-elf instead.
The full story :
I am trying to port gcc 3.3.2 and binutils 2.14 to the (unsupported) target
m68k-atari-mint (Atari ST)
My host is i686-pc-cygwin.
Patches are available for old versions here :
http://membres.lycos.fr/pmandin/download/diff/
In the past, I successfully ported gcc 3.2.3 and binutils 2.13.2.1 to that
platform.
I know that m68k-aout is a very obsolete format, but it is the format which is
the closest to the native Atari ST executable format. That's why the original
author of the patches used that format.
So I cannot use a format other than m68k-aout without rewriting completely the
patches...
That's why I'm stuck with that old target not defining BFD_ASSEMBLER.
> 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 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).
Here is what happens with my patched-ld : It tries to relocate the bogus 16-bit
address.
- 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).
- If the resulting address is more than 16-bit wide, I get an error "relocation
truncated to fit: 16 *ABS*" from the linker, and no executable file is
generated.
Note that the first case is very dangerous : an invalid program is generated,
without any warning. That's what happened when I compiled the old versions of
gcc, but I didn't notice it. Now, with gcc 3.3.2, the second case happens when
I try to link some programs with libgcc.a (because the related bug is present
in gcc/config/m68k/lb1sf68.asm).
In my small test case, if I define the constant before using it, everything is
OK : no bogus reloction is generated, and when loaded in memory, the constant
is still 3 as expected.
Vincent.