PLT Problems in uBoot on MCF548x

[Maciej W. Rozycki]

On Tue, 30 Jul 2024, Peter LaDow wrote:

> What is going on with the PLT?  Is it supposed to be "fixed up" before
> calls through it?  Or is it supposed to be populated with the correct
> offsets/values?

 A PLT is used in a SVR4 environment involving dynamic shared objects to 
handle symbol resolution (including possibly lazy binding, where the 
resolution of a function symbol is deferred to until the function is 
actually called) and pre-emption at load and run time (i.e. where an 
exported symbol defined in one object is overridden in a dynamic load by a 
symbol of the same name coming from another object).

 Since U-Boot is a bare metal environment I gather none of this stuff 
matters, right?

> All the code is compiled with -fPIC, and ultimately linked with:

 I gather you compile your code with -fPIC only to have it relocated at 
run time (I've seen the mention of copying from Flash to RAM somewhere) 
rather than to load it as a dynamic shared object in a multi-object setup, 
right?

 Why not -fPIE then, since you link with -pie anyway?  This would at least 
tell GCC that symbol pre-emption is not going to happen as no symbol is 
ever pre-empted in the main executable by a dynamic shared object.  I know 
nothing of the m68k target, but with the relevant targets that I am 
familiar with compilation options affect relocation operators emitted by 
GCC in the assembly generated, so I suspect that lone option itself might 
make the PLT go away.

 Otherwise there's also the `-fvisibility=hidden' GCC option you might 
experiment with, which prevents symbols from being exported to other 
objects in a dynamic load (and hence suppress PLT generation as those 
symbols will both resolve locally and will not ever be needed by other 
dynamic shared objects for any reference, including to ensure function 
pointer equality).

 Please refer to the GCC manual for further details concerning these 
options.

> 68k-linux-ld.bfd -n -pie -z noexecstack --no-warn-rwx-segments
> --gc-sections -pie -Bstatic  --no-dynamic-linker -z notext
> --build-id=none -Ttext 0x0 -o u-boot -T u-boot.lds
> arch/m68k/cpu/mcf548x/start.o --whole-archive (... snipped for
> brevity) --no-whole-archive arch/m68k/lib/lib.a -Map u-boot.map

 If you still get a PLT produced with the compilation options discussed 
above, then your final resort would I guess be forcing all the symbols 
local in the final link, such as with a trivial linker version script.  
Please refer to the `--version-script=...' LD option and the VERSION 
command in the LD manual for further details.

 Though I suspect it won't be needed and the PLT is only produced because
the compilation model chosen resulted in PLT relocation being present in 
the assembly generated by GCC.  As I say, I know nothing about the m68k 
target itself and these are generic suggestions which may or may not help.  
I hope that they do though.

  Maciej