PLT Problems in uBoot on MCF548x

[Maciej W. Rozycki]

On Wed, 7 Aug 2024, Peter LaDow wrote:

> >  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.
> 
> Linker script and memory map
> 
> Address of section .text set to 0x0
> 
> .text           0x0000000000000000    0x2c204
> arch/m68k/cpu/mcf548x/start.o(.text*)
> .text          0x0000000000000000      0x554 arch/m68k/cpu/mcf548x/start.o
>                0x0000000000000400                _start
>                0x0000000000000474                relocate_code
>                0x000000000000050c                _fault
>                0x0000000000000510                _exc_handler
>                0x0000000000000532                _int_handler
>                0x0000000000004000                . = DEFINED (env_offset)?env_o

 So how do the definitions of `_start' and `_fault' look like in start.c 
(and start.s produced)?

> >  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.
> 
> The _start symbol is not mentioned in the linker script, other than an
> ENTRY(_start).  I tried removing that, and there's no change in the
> output.

 Yeah, this just tells the linker how to set the entry point in the ELF 
file header.

> >  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?
> 
> There are relocations in start.o (which contains _start, _fault, and
> _vectors).  There are R_68K_32 and just a few R_68K_PC16.  I note that
> _fault is generated as R_68K_PC16.  But the beginning of the vector
> table does show _start (the remainder are _fault):
> 
> Relocation section '.rela.text' at offset 0x9e4 contains 271 entries:
> Offset     Info    Type            Sym.Value  Sym. Name + Addend
> 00000004  00000f01 R_68K_32          00000400   _start + 0
> 00000008  00001001 R_68K_32          0000050c   _fault + 0

 OK, that does not explain the difference between how the relocations get 
calculated, so it has to be the symbol definition as previously suspected.

> I'm not sure what you mean by "referring no symbol."  What am I looking for?

 Stuff like below:

Relocation section '.rela.dyn' at offset 0xab0 contains 78 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000003f7a8  000000000016 R_PPC64_RELATIVE                     158f0

Observe that this is a dynamic relocation and it refers no symbol and only 
has an addend supplied which will be relocated by the base address at load 
time.  This is a data location which referred a symbol at static link time 
that resolved locally, so all that remains to be done at load time is to 
adjust for the ultimate location in the virtual address space.

 See also the reply from Andreas who is an m68k expert.

  Maciej