PLT Problems in uBoot on MCF548x

[Peter LaDow]

On Wed, Aug 7, 2024 at 4:10 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>  I was going to ask further questions, but to cut it short I had a look at
> a U-Boot checkout I previously used for RISC-V development.  There is no
> arch/m68k/cpu/mcf548x/ subdirectory there, but there are other board files
> in arch/m68k/cpu/*/, and start.S files among others.

Right.  I'm adding support for the MCF5484/5.  I used the
arch/m68k/cpu/mcf5445x/ as a model (with some other items).  And I see
the same problem when I try to compile the MCF5445x flavors (e.g.
stmark2 and amcore) and MCF5301x flavors (e.g. M53017EVB).  These all
put 0x00000000 for _start in the vector table, and fail on the link to
memset() in board_init_f_init_reserve().

>  Obviously to hide symbols in handcoded assembly you need to use the
> `.hidden' pseudo-op, just as I told you before.  But it seems it shouldn't
> be necessary (though of course you can still do it for consistency) as all
> the arch/m68k/cpu/*/start.S files have code to handle dynamic relocations
> themselves, and obviously your executable has to have some as it has to
> relocate global data (for the `_fault' symbol at the very least).  I do
> hope you have carried this code over to your version.

I did try your suggestion of .hidden, and actually found a reference
in another file to _start.  If I remove that reference, it links
correctly.  Even with .globl in start.S.

The reference is in lib/lmb.c.  And looking at the relocations in the
object file, references to _start:

Relocation section '.rela.text.arch_lmb_reserve_generic' at offset 0x6404 contai
ns 3 entries:
Offset     Info    Type            Sym.Value  Sym. Name + Addend
0000005c  00004e04 R_68K_PC32        00000000   lmb_reserve + 0
0000007e  0000500b R_68K_GOT16O      00000000   _start + 0
00000086  00004e04 R_68K_PC32        00000000   lmb_reserve + 0

Symbol table '.symtab' contains 93 entries:
  Num:    Value  Size Type    Bind   Vis      Ndx Name
    0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
    ...
   80: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND _start

I wonder it is GOT16O rather than PC32 here ....

>  With the information available I can see no reason for `_fault' and
> `_start' to be treated differently.  You may have to investigate it
> yourself why it happens, for example by starting with a trivial start.S
> file that only has definitions and data references to these symbols, and
> if output produced from that looks sound, then add other pieces gradually.

The problem, it seems, is that nobody outside of start.S references
_fault, whereas _start is referenced elsewhere.

>  I'm afraid I can't help you beyond this point, good luck!

I'm very appreciative of the help you've given so far.  I hope the
above information may shed some light on this.

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