PLT Problems in uBoot on MCF548x

[Peter LaDow]

One final note.  This is an embedded system.  In this case I don't
have a loader/dynamic linker.  Are there some options I can use to
turn this off?  Or a way to fixup got_plus_4 and got_plus_8 at link
time?

I tried "-fno-plt" and "-static" but I still get the same results.

On Wed, Jul 31, 2024 at 10:13 AM Peter LaDow <pladow@gmail.com> wrote:
>
> 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.



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