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

[Jerry Van Baren <gerald.vanbaren@ge.com>]

vb wrote:
> On Fri, Jul 25, 2008 at 7:33 AM, kenneth johansson <kenneth@southpole.se> wrote:
> 
>> here is a patch to generate dynamic relocations in the elf file. What is
>> the next step? objcopy -j .rela.dyn -O binary  u-boot dyn_reloc_table ??
>>
>> ----------------
>> --- config.mk
>> +++ config.mk
>> @@ -215,7 +215,8 @@
>>
>>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>>
>> -LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
>> +#LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
>> +LDFLAGS += -Bstatic -shared -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
>>  ifneq ($(TEXT_BASE),)
>>  LDFLAGS += -Ttext $(TEXT_BASE)
>>  endif
>>
> 
> Interesting, but after this step we have a file which can't be
> converted to a runnable binary without resolving the relocation
> information first, right? This is not good then, as we need something
> to run from reset.
> 
> I think this discussion covers much more ground than needed: certainly
> the problem of running the same executable at different addresses has
> been solved many times over, for different architectures and file
> formats. The thing is that unless we want the loader be part of u-boot
> we can not use those standard solutions. And I don't think we want,
> because it would be an unnecessary complication.
> 
> I still believe that my original suggestion of determining the
> addresses of pointers to relocate by comparing to stripped binaries is
> the simplest way to do it across architectures. Apparently the same
> could be achieved by using -mrelocatable on powerPc, this still
> remains to  be seen.
> 
> cheers,
> /vb

Well, to circle back around, Grant Likely *DID* ELF-based relocation 
*SUCCESSFULLY* so it *CAN* be done the right way.  He just didn't have a 
full recipe that worked over all "popular" compiler versions, didn't 
have the time to identify /why/ it didn't work on certain compiler 
versions, and didn't try to run on architectures that he didn't have 
physical access to.

Doing the relocation the right way will be much more future-proof than 
doing it a different wrong way.

The relocation information is in the ELF file until and unless we remove 
it.  "Normal" ELF executables retain that relocation information... that 
is exactly what the "L" (it) is for.  The linux loader (elf loader) 
loads an executable into an arbitrary memory location and relocates it 
by fixing up addresses based on the relocation table.

To reiterate, Grant had a proof-of-concept (well beyond p-o-c, actually) 
that did everything you are asking for, but the right way and even in 
the same architecture that you are interested in.  Despite the chest 
beating that has gone on in this thread about supporting other 
architectures, I'm 100% positive that they are also supported with fixup 
tables, if only we knew enough to use them.

You can stand on the *shoulders* of giants or their toes.

Best regards,
gvb