Re: Fail to build libgcc_s for 060

[Frank Wille <frank%phoenix.owl.de@localhost>]

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)

Looks like some 16-bit PC-relative PLT-calls have come out of range,
i.e. the jump-destination is more than 32K away.


> It seems strange that libgcc would not build for 68060, but -m68060 is 
> really the only thing I've manipulated here; looking at the compile flags 
> for the (generated asm) floatex.pico, it looks like:
> [...]

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

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.


>   _floatex.S -o _floatex.pico
> 
> ..and there's indeed nothing else funky going on with the compiler flags.

Probably not. Besides that -m68060 might have generated a little bit larger
.text section, because some 020 or 88x instructions have to be emulated by
inline code (this is what you wanted, to avoid the emul traps).

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.


> This whole build machinery is pretty opaque to me, so I'm not sure how to 
> proceed. Surely it must be possible to build the target gcc specifically 
> for 68060?

I have no clue about that build machinery either, but maybe you want to
check _floatex.S and look for the $_exception_handler calls in it.

Perhaps they can be converted to 32-bit PC-relative calls, which will
result in R_68K_PLT32 relocations.

-- 
Frank Wille