Re: gcc 3.0: -m68000 -fpic generates invalid code

[Andreas Schwab <schwab at suse dot de>]

"Alexander Aganichev" <AAganichev@hypercom.com> writes:

|> Adreas,
|> 
|> |>> gcc 3.0 generates invalid code when -m68000 -fpic options given. Here is sample test:
|> |>>
|> |>> test.c:
|> |>> int foo(int a);
|> |>> int foo2(int a) {
|> |>>   return foo(a);
|> |>> }
|> |>>
|> |>> The output from compiler contains `bsr.l' instruction which is not available on m68000.
|> |>For which target did you configure the compiler?
|> 
|> I've tried both m68k-elf and m68k-coff.
|> 
|> |> Note that gcc does not support -fpic with -m68000 when using ELF,
|> 
|> I don't see any reason for that strange behaviour. There's no problem to generate proper code, just
|> do not add `.l' after `bsr' instruction. Something like:

The PLT layout requires 68020+, so it does not make sense to support the
68000.

|> if(pic == 1)
|>   return "bsr ...";
|> else /* since pic == 2 is not supported on m68000 that's ok */
|>   return "bsr.l ...";
|> 
|> Though the second instruction should be generated by ld's relaxer (as far as I understand the way
|> that gcc and binutils should interact), so the proper way to fix will be just removing `.l' after
|> `bsr'. But I'm not sure that everything will still works when saying this words :-)

If the bsr cannot be relaxed to bsr.l than you won't be able to create a
shared library bigger than 32K.  Relaxing bsr to jmp defeats the whole
purpose of shared libraries.  This is independent of -fpic vs -fPIC, this
only affects GOT references, and is only a performace issue.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5