bug-binutils
[Top][All Lists]
Advanced

[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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]