PLT Problems in uBoot on MCF548x

[Peter LaDow]

This is a huge help!  Thank you!

I had hoped your suggestions would help with one other issue.  I
suspected they had the same cause, but apparently not.

In the startup code, the first 1Kbyte is a vector table.  Offset 0 is
the initial stack pointer and offset 4 is the initial program counter.
In start.S I have:

_vectors:
  .long 0x00000000  /* Initial stack pointer */
  .long _start             /* Initial program counter */
  .long _fault             /* Exception vectors */
  ...
  .long _fault

However, after linking, _start is populated with 0x00000000:

  Contents of section .text:
  00000 00000000 00000000 0000050c 0000050c  ................
  00010 0000050c 0000050c 0000050c 0000050c  ................
  00020 0000050c 0000050c 0000050c 0000050c  ................

It looks like _fault is populated just fine.  Both _start and _fault
are defined in the same compilation unit.  I don't know why one links
fine and the other does not.

And your suggestions below did fix the PLT issues, but not this one.

On Wed, Jul 31, 2024 at 2:22 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>  Since U-Boot is a bare metal environment I gather none of this stuff
> matters, right?

Right.

>  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?

True.  After the startup code configures the hardware (i.e. enable the
SDRAM), it relocates itself to RAM.

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

Using -fPIE (or -fpie) didn't work.  Still generating calls to the
PLT.  Though it did make the disassembly more clear (now with a branch
to <.plt+offset> instead of <_etext+offset>).

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

This did help.  I do not see calls into the PLT.  I see direct branches:

   f576:       4878 00c0       pea c0 <_vectors+0xc0>
   f57a:       42a7            clrl %sp@-
   f57c:       2f02            movel %d2,%sp@-
   f57e:       61ff 0000 f9b8  bsrl 1ef38 <memset>

And per the symbols:

  $ m68k-linux-gnu-nm -n u-boot
  ...
  0001ef38 t memset
  ...

I do note that this did not change the relocation records in the
object files.  Still says R_68K_PLT32.  However, after linking, these
are direct calls.

Thanks for the help!
Pete
--
To love for the sake of being loved is human, but to love for the sake
of loving is angelic. -- Alphonse de Lamartine.