PLT Problems in uBoot on MCF548x

[Maciej W. Rozycki]

[Cc-ed back to the mailing list (I hope you don't mind) as Gmail doesn't 
want to accept e-mail from here and you wouldn't receive it otherwise.  
Also someone else might want to chime in, in particular who knows m68k.]

On Tue, 6 Aug 2024, Peter LaDow wrote:

> > > 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.
> >
> >  Has a dynamic relocation been produced by any chance for the `_start'
> > reference?  What does `readelf -rs' say for your linked executable?
> 
> With respect to _start, there are only two references.
> 
> First:
> 
> Symbol table '.dynsym' contains 8 entries:
>   Num:    Value  Size Type    Bind   Vis      Ndx Name
>     ...
>     4: 00000400     0 NOTYPE  GLOBAL DEFAULT    1 _start
>     ...

 I find this already suspicious.  It means that `-fvisibility=hidden' 
wasn't applied to this symbol or its visibility would be HIDDEN rather 
than DEFAULT (or the symbol not propagated to the dynsym table in the 
first place).

 Can you double-check how the definitions of `_fault' and `_start' look 
like?  If you're not sure where they come from after all (which can 
sometimes be confusing), then use the `-M' option to LD to print the link 
map, and it'll tell you the symbol's originating object file or whether 
it's come from a linker script instead.

 If it came from a piece of handcoded assembly, it would have to have the 
hidden visibility applied also by hand, with the `.hidden _start' 
pseudo-op, typically placed near the symbol definition.  For a linker 
script definition there are the HIDDEN and PROVIDE_HIDDEN commands.

 Then are there no dynamic relocations at all, not even relative ones 
referring no symbol?  If so, then can you run `readelf -r' on the object 
module containing `_vectors' stuff and see what static relocations have 
been produced at assembly time?

> But I note here that _fault is not present in this table.

 Which is what I'd expect for `_start' as well.

> The other is just in the symbol table:
> 
> Symbol table '.symtab' contains 1658 entries:
>  ...
>  1512: 00000400     0 NOTYPE  GLOBAL DEFAULT    1 _start
>  ...
> 
> But I'm pretty sure that is not relevant.

 It is; I expected this only rather than a dynamic symbol, which only 
makes things worse.

> >  Please note that this puts the toolchain to if not beyond the limits.
> > The intent for the `-fPIC' option is to handle dynamic shared objects in
> > SVR4 hosted environments and it may not fulfil your bare-metal needs.
> 
> To be fair, I'm not the author of u-boot or its build system.  I'm
> only trying to add a new board with a similar family CPU.  I've been
> on the u-boot mailing list, and they indicate that a closely related
> system builds and executes just fine.  From what I can tell, it
> suffers the same problems as my build.  But I can't test their
> configuration and they can't test mine.  Best I can do is try to
> understand why the tools are not generating things cleanly.

 Or rather why they can't stand the abuse.

> >  For bare metal the usual approach is to compile as regular static code
> > and link at the intended ultimate virtual memory address (whatever that
> > means in a bare-metal environment) aka VMA and use the load memory address
> > aka LMA to tell the loader (which can be a disk loader, a network client,
> > a Flash memory programmer, etc.) where to put the image initially before
> > passing control to it.
> 
> Right.  As I've done with ARMv7 systems before.  But again, this
> linker script is theirs and they claim it works.

 Sometimes things work by chance and stop doing so with supposedly an 
innocent change.  Given the amount of tool chain abuse I can see here I 
wouldn't be surprised if it was the case.

  Maciej