PLT Problems in uBoot on MCF548x

[Peter LaDow]

Ok, I did some reading through the SysV M68K ABI (part3 here:
https://m680x0.github.io/ref/sysv-m68k-abi-part3.pdf).

I see in my earlier analysis:

  00023ad4 <.plt>:
   23ad4:       203c 0000 c95a  movel #51546,%d0
   23ada:       2f3b 08fa       movel %pc@(23ad6 <.plt+0x2>,%d0:l),%sp@-
   23ade:       203c 0000 c954  movel #51540,%d0
   23ae4:       207b 08fa       moveal %pc@(23ae0 <.plt+0xc>,%d0:l),%a0
   23ae8:       4ed0            jmp %a0@

This load of A0 is with the address of the dynamic linker.  So, this
PC relative load of 0x30434 (at "got_plus_8" as the ABI calls it) is
the dynamic linker.  Per the ABI:  "The program then jumps to the
address in the third global offset table entry (got_plus_8), which
transfers control to the dynamic linker."

And prior to that, it "places the value of the second global offset
table entry (got_plus_4) on the stack, thus giving the dynamic linker
one long word of identifying information."

But looking at the final linked output, both got_plus_4 and got_plus_8 are 0:

Contents of section .got.plt:
3042c 0003037c 00000000 00000000 00023af8  ...|..........:.
3043c 00023b10 00023b28 00023b40 00023b58  ..;...;(..;@..;X
3044c 00023b70 00023b88 00023ba0 00023bb8  ..;p..;...;...;.
3045c 00023bd0 00023be8 00023c00 00023c18  ..;...;...<...<.
3046c 00023c30 00023c48 00023c60 00023c78  ..<0..<H..<`..<x
3047c 00023c90                             ..<.

So, what *should* be in got_plus_4 and got_plus_8?  How do these
entries get populated?

(Note:  I see this same set of 0's in got_plus_4 and got_plus_8 on the
MCF5445x, which they claim works.)


On Wed, Jul 31, 2024 at 7:59 AM Peter LaDow <pladow@gmail.com> wrote:
>
> With "readelf -e" there is a single RELA section:  .rela.dyn.  This is
> handled later in the code when the code itself is relocated to RAM.
> At this point, the code is executing from flash.
>
> There are R_68K_RELATIVE, R_68K_32, and R_68K_JMP_SLOT entries when I
> use "readelf -r."
>
> One of these does map to memset.  The first lookup in the PLT:
>
>    23c0c:       203c 0000 c85a  movel #51290,%d0
>    23c12:       207b 08fa       moveal %pc@(23c0e <.plt+0x13a>,%d0:l),%a0
>    23c16:       4ed0            jmp %a0@
>
> Does map to memset:
>
>   $ m68k-linux-gnu-readelf -r u-boot
>   ...
>   00030468  00005315 R_68K_JMP_SLOT    0001f0b0   memset + 0
>   ...
>
> And indeed, memset is at 0x1f0b0:
>
>   $ m68k-linux-gnu-nm -n u-boot
>   ...
>   0001f0b0 T memset
>   ...
>
> But it's not clear to me how this information is used by the PLT.
>
> I'm not sure what you mean about "relocations against the relevant
> .got.plt entry."  I don't see anything that points to any addresses in
> .got.plt.
>
> And finally, your question about if the "relocations applied early
> enough."  I don't think so.  The startup code does not do any
> relocations at this point.  There is code to relocate uboot out of
> flash to RAM, but we aren't there yet.  This uses __rel_dyn_start and
> __rel_dyn_end, but this happens after the system is configured (SDRAM,
> etc.).  Indeed, relocation is the very last step before entering the
> main loop.
>
> There is another platform, the MCF5445x, which I've used as a model.
> This too uses PLT (rather than GOT160 relocations as other Coldfire
> platforms do).  My startup code is nearly identical (I stripped on the
> NAND boot and SBF).  And that code does not do any fixups or other
> relocations until later.
>
>
>
> On Tue, Jul 30, 2024 at 5:03 PM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Tue, Jul 30, 2024 at 12:28:13PM -0700, Peter LaDow wrote:
> > > 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
> >
> > Have you examined u-boot using readelf to see whether there are any
> > RELA type sections?  If so, do you see a relocation against the
> > relevant .got.plt entry?  Also, are these relocations applied early
> > enough, ie. before the board_init.c memset call?
> >
> > --
> > Alan Modra
>
>
>
> --
> To love for the sake of being loved is human, but to love for the sake
> of loving is angelic. -- Alphonse de Lamartine.



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