PLT Problems in uBoot on MCF548x

[Peter LaDow]

I'm working on port uBoot to the Coldfire MCF548x.  I'm running into
issue post-link when trying to call functions through the PLT.  The
problem I'm running into is that eventually calls to functions end up
jumping to 0x00000000.

(Note that the MCF52xx and MCF53xx use GOT160 relocations, but the
MCF548x use PLT32 relocations.  The problems I'm having are related to
the PLT, but I'm not sure what is occurring.)

This is an embedded system.  And I'm not sure how the PLT is
populated.  I dug through the source code of binutils with no luck
trying to find the code for the PLT section.  I don't know what this
does or how it does it.  But I can trace through things and see what
is happening.

What is going on with the PLT?  Is it supposed to be "fixed up" before
calls through it?  Or is it supposed to be populated with the correct
offsets/values?

All the code is compiled with -fPIC, and ultimately linked with:

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

I've been asking on the uBoot list, but no resolution yet.  There is a
similar board, MCF5445x, which uses the PLT, and they have it working.
But I trace the code the same way and see the same issue--ultimately
calls to memset should resolve to 0.  I don't see any fixup of .plt or
.got.plt.  I'm sure I'm missing something, but I cannot figure out how
to get my code to be properly generated.

Here's my trace of what happens on my board.

When compiling part of the startup code in common/init/board_init.c,
it calls memset.  The final compiled output yields:

    f5e0:       4878 00c0       pea c0 <_vectors+0xc0>
    f5e4:       42a7            clrl %sp@-
    f5e6:       2f02            movel %d2,%sp@-
    f5e8:       61ff 0001 4622  bsrl 23c0c <_etext+0x138>

The "bsrl" jumps to the .plt section.

When I follow the chain through the PLT call to memset, it does some
lookups in the .got.plt section.  Walking the chain, it ends up with a
jump to address 0x00000000.

Now, from the above call, 0x23c0c is in .plt.  The code here:

   23c0c:       203c 0000 c85a  movel #51290,%d0
   23c12:       207b 08fa       moveal %pc@(23c0e <.plt+0x13a>,%d0:l),%a0
   23c16:       4ed0            jmp %a0@

So, this does a lookup relative to PC.  The PC relative lookup is
0x23c12 + 2 (CF adds 2 for effective address) - 6 (extension word
displacement) + 51290*1 (register D0, scale of 1) = 0x30468.

Now, 0x30468 is in the .got.plt section:

  Contents of section .got.plt:
   ...
   3045c 00023bd0 00023be8 00023c00 00023c18  ..;...;...<...<.
   ...

So, the code jumps to 0x23c18.  The disassembly at 0x0x23c18:

   23c18:       2f3c 0000 0090  movel #144,%sp@-
   23c1e:       60ff ffff feb4  bral 23ad4 <.plt>

Which jumps to 0x23ad4:

  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@

Ultimately here we see A0 get loaded with (presumably?) the address of
memset.  Again, this is a PC relative load into .got.plt.  So, it
loads from 0x23ae4 + 2 - 6 + 51540 = 0x30434.

And 0x30434 is in .got.plt:

  Contents of section .got.plt:
   3042c 0003037c 00000000 00000000 00023af8  ...|..........:.

And we see at 0x0x30434 a value of 0x00000000.  Meaning the code jumps
to address 0.  Which cannot be correct.

Thanks,
Pete


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