[U-Boot-Users] Changing u-boot relocation scheme

[Kenneth Johansson <kenneth@southpole.se>]

On Wed, 2008-07-23 at 23:45 -0700, vb wrote:
> Wolfgang, thank you for your reply, let me try to explain myself a bit clearer:
> 
> On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <wd@denx.de> wrote:
> > In message <f608b67d0807231039i434e96dbvda86590776db2cb0@mail.gmail.com> you wrote:
> >
> >> some companies). If these added modules were not written in position
> >> independent manner (namely, using structures with multiple stage
> >> indirect pointers interleaved with data), the effort to make these
> >> modules work in u-boot is very exhausting.
> >
> > I don't understand what you mean. Either you link statically with the
> > U-Boot image, or you use standalone programs. In both situations no
> > such problem as described by you exists.
> >
> 
> we talk here about modules statically linked into the u-boot image.
> Allow me to illustrate the problem I am trying to solve. Consider
> adding this code to a u-boot source file on a ppc460gt platform:
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> 87a88,105
> >
> > int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
> >
> > int  (*pf)(struct cmd_tbl_s *, int, int, char *[]) = do_ptrt;
> >
> > int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> > {
> >       printf ("pointer is %p\n", pf);
> >       printf ("function is %p\n", do_ptrt);
> >       return 0;
> > }
> >
> > U_BOOT_CMD(
> >       ptrt, CFG_MAXARGS, 1,   do_ptrt,
> >       "ptrt\n",
> >       ""
> > );
> >
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> And this is what happens when this command is invoked:
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> => ptrt
> pointer is fffb2754
> function is 0ffb7754
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> So, the value of 'pf' is equal to the address of do_ptrt() *before*
> relocation. The fact that there is a GOT and a sophisticated linker
> script did not prevent this from happening.


This is due to a u-boot on powerpc not doing the right things when it is
relocating itself. The code to do the right things exist but is
currently disabled.  

What is missing right now is that to properly fix function pointers
stored in data section we have to compile with -mrelocatable flag to get
gcc to create a fixup table so we later at runtime can just go over that
table and correct all function pointers. 

This is currently not done as there was some problems with it that
people thought was due to toolchain issue. I'm not so sure it is, the
code to generate this fixup has been in gcc since mid 90's and has not
seen many changes and the linker should not have to know about it as
it's just a normal relocataion for it. My take is that some targets did
something special with trying to fixup some pointers themselves and fail
when it's done correctly.

this is the only issue I'm aware of regarding relocation and if you
enable this for your board all your problems goes away.