[U-Boot] [PATCH] futile c relocation attempt

J. William Campbell jwilliamcampbell at comcast.net
Wed Oct 6 16:50:40 CEST 2010


  On 10/6/2010 2:43 AM, Graeme Russ wrote:
> On 06/10/10 01:48, Reinhard Meyer wrote:
>> ---
>>   arch/arm/cpu/arm926ejs/start.S |    8 ++++-
>>   arch/arm/lib/board.c           |   57 +++++++++++++++++++++++++++++++++++++++-
>>   include/configs/top9000_9xe.h  |    1 +
>>   3 files changed, 63 insertions(+), 3 deletions(-)
>>
> I had a quick look at this and nothing is jumping out at me. Of course I am
> not familiar with ARM asm...
>
> I don't see any reason why this ultimately will not work eventually. You
> may be having some issues with the transition from asm->C->asm through the
> relocation - This was an especially painful thing for me involving an
> intermediate trampoline which I have only recently figured out how to remove.
>
> Maybe some memory barriers are needed to stop the C optimiser mangling things?
>
> I am sure what you have is very close to the real solution :)
>
> I do think the main relocation fixup loop can be moved into a common
> library in which case we can add additional case statements. The nice thing
> is that x86 as all Type 8 which is specifically allocated to x86 so my "if
Hi All,
       I think that type 8 IS NOT allocated to the 386. For instance, 
R_PPC_ADDR14_BRTAKEN also has a value of 8. So does R_ARM_ABS8. I think 
that there will be a lot of #ifdefs just to keep the references 
symbolic. Many of the different platform  relocation types will come out 
to be the same code in the switch statement, but different symbolic 
names. There will also be some entries that are processor specific and 
have no equivalent on other processors. I think it would be a good idea 
to use the symbolic values of the Relocation types (as opposed to 
integer constants), as it will make the code clearer. There are sort of 
two ways to organize the code inside the switch statement. Since the 
code inside the switch statement is very short, it might be best for 
each architecture (ELF format) to be  bunched together, even at the 
expense of repeating the same executable statements that some other 
formats may use, as follows:
#ifdef PPC
            case R_PPC_ADDR32:  /* S + A */
<code to do the deed>
               break;

            case R_PPC_RELATIVE:  /* B + A */
<code to do the deed>
               break;
#endif
#ifdef I386
            case R_386_32:  /* S + A */ /* I think this is the other 
location type Graeme used, but I could be wrong */
<code to do the deed>
               break;

            case R_386_RELATIVE:  /* B + A */
<code to do the deed>
               break;

#endif
#ifdef ARM
            case R_ARM_ABS32:  /* S + A */ /* I don't remember the ARM 
relocation types used  */
<code to do the deed>
               break;

            case R_ARM_REL32:  /* B + A  - P */
<code to do the deed>
               break;

#endif

Or we could group the various Relocation types by what they actually do:
#ifdef PPC
            case R_PPC_ADDR32:  /* S + A */
#endif
#ifdef I386
            case R_386_32:  /* S + A */ /* I think this is the other 
location type Graeme used, but I could be wrong */
  #endif
  #ifdef ARM
            case R_ARM_ABS32:  /* S + A */ /* I don't remember the ARM 
relocation types used  */
#endif
<code to do the deed>
               break;

#ifdef PPC
            case R_PPC_RELATIVE:  /* B + A */
#endif
  #ifdef I386
             case R_386_RELATIVE:  /* B + A */
#endif
<code to do the deed>
               break;

#ifdef ARM
            case R_ARM_REL32:  /* B + A  - P */
<code to do the deed>
               break;
#endif

Note that the ARM_REL32 is defined differently than the PPC/I386 
relative, FWIW. I also don't know what to use for the names of the 
binary formats. It would be nice if we could use something already in 
the header files? Thoughts on all this solicited!

Best Regards,
Bill Campbell
>> TEXT_BASE" checks can be kept. For size freaks, we could litter the code
> with #ifdefs to remove un-needed cases ;)
>
> Interestingly, ARM is adding gd->reloc_off while x86 is subtracting
> gd->reloc_off. If this is correct, I need to change the calculation of
> gd_reloc_off to be consistent
Adding is the way the specifications define it. add B+A.

Best Regards,
Bill Campbell
> Regards,
>
> Graeme
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>



More information about the U-Boot mailing list