Frank Wille | 4 Jan 19:10 2010
Picon

Re: libm compilation failing in -current

John Klos wrote:

>> Do you have any local diffs? Did you try a clean build?
>
> I just tried a completely fresh tree on an amd64 system and got the
> same issue. I'm about to try on a macppc machine.

While I was trying to reproduce your 68060 userland build problem I ran into
exactly this DT_TEXTREL warning. How did you solve it?

I analyzed some object files and found out that there are indeed 36 objects
in libm_pic.a which have a .rela.text section. For example in s_atan.so the
relocation looks like this:

00000000 <atan>:
   0:   60ff 0000 0000  bral 2 <atan+0x2>
                        2: R_68K_PC32   __fplsp060_0038

All are coming from src/lib/libm/arch/m68060 and calling functions from
Motorola's 68060 floating point library (which is the reason it didn't
happen to anybody else before ;).

Those 32-bit PC-relative relocs are definitely those which cause the
warning "creating a DT_TEXTREL in a shared object", although I fail to
understand why a PC-relative reference inside the same .text section needs
a DT_TEXTREL? The linker should resolve the reference and the reloc entry
disappears...

So either the linker's warning is wrong or the 68060-fplsp part has to be
changed to use PLT-relocs.
(Continue reading)

David Laight | 4 Jan 21:33 2010
Picon

Re: libm compilation failing in -current

On Mon, Jan 04, 2010 at 07:10:48PM +0100, Frank Wille wrote:
> 
> I analyzed some object files and found out that there are indeed 36 objects
> in libm_pic.a which have a .rela.text section. For example in s_atan.so the
> relocation looks like this:
> 
> 00000000 <atan>:
>    0:   60ff 0000 0000  bral 2 <atan+0x2>
>                         2: R_68K_PC32   __fplsp060_0038
> 
> All are coming from src/lib/libm/arch/m68060 and calling functions from
> Motorola's 68060 floating point library (which is the reason it didn't
> happen to anybody else before ;).
> 
> Those 32-bit PC-relative relocs are definitely those which cause the
> warning "creating a DT_TEXTREL in a shared object", although I fail to
> understand why a PC-relative reference inside the same .text section needs
> a DT_TEXTREL? The linker should resolve the reference and the reloc entry
> disappears...

Only if you ask it to ...
The default for elf is to allow an application to override symbols provided
by a library - even for calls withing the library itself.
There is a linker option to do the immediate fixups.

	David

--

-- 
David Laight: david <at> l8s.co.uk

(Continue reading)

Ignatios Souvatzis | 5 Jan 13:58 2010
Picon

Re: libm compilation failing in -current

On Mon, Jan 04, 2010 at 07:10:48PM +0100, Frank Wille wrote:
> John Klos wrote:
> 
> >> Do you have any local diffs? Did you try a clean build?
> >
> > I just tried a completely fresh tree on an amd64 system and got the
> > same issue. I'm about to try on a macppc machine.
> 
> While I was trying to reproduce your 68060 userland build problem I ran into
> exactly this DT_TEXTREL warning. How did you solve it?
> 
> I analyzed some object files and found out that there are indeed 36 objects
> in libm_pic.a which have a .rela.text section. For example in s_atan.so the
> relocation looks like this:
> 
> 00000000 <atan>:
>    0:   60ff 0000 0000  bral 2 <atan+0x2>
>                         2: R_68K_PC32   __fplsp060_0038
> 
> All are coming from src/lib/libm/arch/m68060 and calling functions from
> Motorola's 68060 floating point library (which is the reason it didn't
> happen to anybody else before ;).

Well, while it might be interesting to have this in a compilable
state, I want to mention that after I did all the work to integrate this
stuff, at least optionally, all benchmarks I ran showed that the
kernel-trapping FPSP (with the normal m68k FPU instruction or whatever
it uses libm) was faster, at least on a otherwise loaded system.

The reason is probably that kernel-FPSP resides at a fixed physical
(Continue reading)

Frank Wille | 5 Jan 22:42 2010
Picon

Re: libm compilation failing in -current

Ignatios Souvatzis wrote:

>> [..DT_TEXTREL..]
>> 00000000 <atan>:
>>    0:   60ff 0000 0000  bral 2 <atan+0x2>
>>                         2: R_68K_PC32   __fplsp060_0038
>> 
>> All are coming from src/lib/libm/arch/m68060 and calling functions
>> from Motorola's 68060 floating point library (which is the reason it
>> didn't happen to anybody else before ;).
>
> Well, while it might be interesting to have this in a compilable
> state, I want to mention that after I did all the work to integrate
> this stuff, at least optionally, all benchmarks I ran showed that the
> kernel-trapping FPSP (with the normal m68k FPU instruction or whatever
> it uses libm) was faster, at least on a otherwise loaded system.

That's disappointing! :|
Under AmigaOS using the 68060 library makes it *much* faster.

> The reason is probably that kernel-FPSP resides at a fixed physical
> address (once the kernel is booted), so needs less cache reloading to
> use.

Hard to believe that it has such an effect.

> I think I posted the benchmark results back then?

Don't remember. 10 years ago? ;)

(Continue reading)

Christos Zoulas | 6 Jan 00:27 2010

Re: libm compilation failing in -current

In article <3c3781387d0.10bbbfc5 <at> mail.pb-owl.de>,
Frank Wille  <frank <at> phoenix.owl.de> wrote:
>Ignatios Souvatzis wrote:
>
>>> [..DT_TEXTREL..]
>>> 00000000 <atan>:
>>>    0:   60ff 0000 0000  bral 2 <atan+0x2>
>>>                         2: R_68K_PC32   __fplsp060_0038
>>> 
>>> All are coming from src/lib/libm/arch/m68060 and calling functions
>>> from Motorola's 68060 floating point library (which is the reason it
>>> didn't happen to anybody else before ;).
>>
>> Well, while it might be interesting to have this in a compilable
>> state, I want to mention that after I did all the work to integrate
>> this stuff, at least optionally, all benchmarks I ran showed that the
>> kernel-trapping FPSP (with the normal m68k FPU instruction or whatever
>> it uses libm) was faster, at least on a otherwise loaded system.
>
>That's disappointing! :|
>Under AmigaOS using the 68060 library makes it *much* faster.
>
>
>> The reason is probably that kernel-FPSP resides at a fixed physical
>> address (once the kernel is booted), so needs less cache reloading to
>> use.
>
>Hard to believe that it has such an effect.
>
>
(Continue reading)

Frank Wille | 6 Jan 13:20 2010
Picon

Re: libm compilation failing in -current

On Tue, 5 Jan 2010 23:27:34 +0000 (UTC)
christos <at> astron.com (Christos Zoulas) wrote:

> > [...]
> > ENTRY($NAME)
> > #ifdef __SVR4_ABI__
> >-   jbra _C_LABEL(__fplsp060_$OFFS)
> >+   bral _C_LABEL(__fplsp060_$OFFS) <at> PLTPC
> > #else
> >    movel %sp <at> (4),%sp <at> -
> >-   jbsr _C_LABEL(__fplsp060_$OFFS)
> >+   bsrl _C_LABEL(__fplsp060_$OFFS) <at> PLTPC
> >    fmoves %fp0,%sp <at> 
> >    movel %sp <at> +,%d0
> >    rts
> 
> Looks good, but you should probably use the PIC_PLT() macro from asm.h

Yes, you're right! I nearly forgot that the same source is used for
building the static library as well. Thanks.

> if bsrl can handle non-plt jumps; otherwise you need an ifdef I think.

It can. The jbra was already turned into a bral with 32-bit PC-relative
relocation before.

--

-- 
Frank Wille

(Continue reading)


Gmane