Re: Fail to build libgcc_s for 060

[Anders Lindgren <ali%dflund.se@localhost>]

On Wed, 10 Apr 2019, Frank Wille wrote:

> On Wed, 10 Apr 2019 10:15:21 +0200 (CEST)
> Anders Lindgren <ali%dflund.se@localhost> wrote:
>
> > libgcc_s_pic.a(_float.pico):(.text+0x8): relocation truncated to fit: R_68K_PLT16 against symbol `$_exception_handler' defined in .text section in libgcc_s_pic.a(_floatex.pico)
[snip]
> Apart from -m68060 there is -fPIE and -fPIC. PIC generates position
> independant code, which was always required for shared objects (calls are
> done relative via PLTs and data accesses relative via the GOT).

Right, I didn't notice one of them was in fact PIE, not PIC. Too used to 
seeing duplicated CFLAGS. %-) No idea what that implies on m68k though.

> PIE might be new (or I didn't notice it in later years). It enables
> address space layout randomization (ASLR) - and I'm not sure if it is
> even meant to work together with PIC. I'm not familiar enough with it
> to give a judgement here.

Normally PIE would imply PIC (you can't randomize the address unless the 
code is position independent, so it makes sense). The gcc man page implies 
that -fPIE generates code that can only be linked into executables, which 
would seem to contradict the usage to build .so objects here, but 
I'm not familiar enough with its use to judge, either.

[snip]
> But here _floatex.S is already an assembler source, which has probably
> hardcoded PC-relative 16-bit calls. My guess it that they no longer work,
> because the distance to their jump-destination in the PLT has just exceeded
> 32K.

Yes, that makes sense. I guess I will have to start digging into where the 
asm comes from, and see if it's easy to just replaces the calls as you 
suggest. I'm one of those weird Amiga nerds who only ever coded C on their 
Amigas, so I don't really know 68k asm, but should probably be able to 
work something out. :-)

[...]

Thanks!
/ali:)