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

[vb]

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 at denx.de> wrote:
> In message <f608b67d0807231039i434e96dbvda86590776db2cb0 at 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.

>> Here is the suggested alternative. I will talk about recent PPC
>> platforms, but it could be done very similar for most of the other
>> platforms I believe.
>
> I don't think so.
>

Admittedly I don't have experience with nearly as many different
platforms as you do, but I don't see why not, is there a specific
fundamental reason on any of the platforms? But even if this does not
work on some, it will work on most.

>> In general the PPC u-boot image consists of three parts: the bulk of
>
> No, this is by far not general, not even for PPC.
>

I used that particular layout to emphasize that care needs to be taken
to remove the fixed address sections (the last 4k memory page in this
case) from the set of modules to link. On other architectures this
would be a different part of the image linked to the reset vector, the
idea remains the same.

>> Then we compare the two images and identify all locations which are
>> different. All these locations are 4 byte aligned, and all differ by
>> the same amount - equal TEXT_BASE. Now we can build a table of offsets
>> which need to be changed when the program is moved into a different
>> location, include this table in the resulting image between the bulk
>> and the startup page, and use this table when relocating code.
>
> Why would we do that? The compiler already generates such a table for
> free - the GOT.
>

well, didn't the example above show that the compiler will not do that
to an arbitrary pointer to a text object?

>> Basically, this implements a poor man's loader, and it will be
>> sufficient in case the image we are dealing with is a flat binary
>> (which is of course the case with u-boot). This will allow to add any
>> code to u-boot without much worries about being able to relocate it
>> properly. We would do away with storing certain structures in certain
>> sections, dealing with GOT, etc.
>
> I don't see how your "poor man's" GOT would be any better than the
> compiler generated one - except that it's horribly non-standard and
> glumpsy?
>

Quite frankly, GOT is also clumsy and even ugly IMHO - it requires a
lot of special treatment, explicit data definitions and linker
scripts, and does not work for arbitrary data as we saw above.

>> I made some experiments, and this seems feasible, this could be done
>> as a local customization, but I would much prefer to release it to the
>> u-boot community and make it part of mainline - will you consider such
>> a patch?
>
> I don't understand which problem you're trying to fix, and I don't see
> that your solution would be any better than what we have now.
>

I beg to differ, the solution I am suggesting will allow to stop
worrying about placing data in special sections, and will allow to
link in third party  modules which use cross segment pointers.

[snip]
>>
>> because the  modules are now part of u-boot, they need to be relocated
>> along with the rest of the image.
>
> U-Boot does this (if statically linked) the very same way like all
> other U-Boot code gets relocated.
>

not for pointers to functions as we saw above, right?

>> > Why isn't it written in position independent manner?
>>
>> because they come from different sources, not concerned with u-boot,
>> and just work and need to be ported as is.
>
> If you want to link against U-Boot, you have to use at least
> compatible compiler options and the U-Boot linker script.
>

well, the example above was inserted in one of u-boot source files, so
it was compiled exactly the way other u-boot modules were compiled.

>> > How is your relocation methodology going to fixup a module's data
>> > structures?
>>
>> The relocation will adjust only pointers to absolute addresses stored
>> in text/data segments.
>
> No.
>

But I think it will and I can demonstrate that.

>> > What pointers are in your data structures?  Why do they need to be
>> > relocated?
>>
>> in some cases data structures include pointers to other data
>> structures, etc. (This is called  'tree' btw, sorry couldn't resist
>> :-)
>
> This should get sorted out correctly when linking.
>

but it does not.

>> > Gcc supports "proper" relocation, if only we knew how to make it work for
>> > all "reasonable" versions of gcc (and Grant's conclusion is that many
>> > versions of gcc in use today do *not* support the relocation).
>> >  <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/36343/>
>>
>> well, if there is a pointer to a data element or to a function stored
>> in a data structure, the .bin image is built and fixed using actual
>> addresses set by the linker. How can gcc help here?
>
> By adding the respective entries to the GOT.
>

and this is what I am trying to avoid, because in my case I need to
link in large chunks of third party code which can't be massaged to
follow the u-boot conventions, and can't be used as downloadable
applications for some platform specific reasons.

>> I am sure it is doable, I am just trying to understand if this would
>> be accepted in general, because it can be done differently depending
>> if one needs to push it upstream or not.
>
> If you invest time in solving such problems, than your time willbe
> much better iinvested if you try to help solving the remaining issues
> with  Grant's code.
>
> What Grant suggests is the way to go. I do not think your approach has
> chances for mainline.
>

I am sorry to hear this, especially since what I suggest would be
completely compiler agnostic and would allow to avoid some of the
limitations one must follow today while adding stuff to u-boot.

cheers,
/vb


> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Nothing in progression can rest on its original plan. We may as  well
> think  of  rocking  a grown man in the cradle of an infant.
> - Edmund Burke
>