[GSOC2013] Dynamic object file loading

[Peng Fan]

Hi Chris.

I have Implement a basic support for ARM now.
The following types are implemented now:

ARM REL TYPE:
R_ARM_JUMP24
R_ARM_ABS32
R_ARM_CALL
R_ARM_MOVW_ABS_NC
R_ARM_MOVT_ABS
R_ARM_V4BX

THUMB32 REL TYPE:
R_ARM_THM_CALL
R_ARM_ABS32
R_ARM_THM_MOVW_ABS_NC
R_ARM_THM_MOVT_ABS
R_ARM_THM_JUMP24
R_ARM_THM_JUMP19

The loader patch is place here:https://gist.github.com/MrVan/5517361
I also noted something when implement the types:
https://docs.google.com/document/d/1vdG3UtU-Vun6_WL9hHv8oV3ZlktCGKYCIBVbtm08y08/edit?usp=sharing
I have not successfully make my tiny6410 board run  in thumb mode.
Thus I manually caculated the relocation for Thumb32, mainly THM_CALL , and
the result is right.
I think each reloc type after implemented should be tested, but because of
the hardware reason, I only tested part.
If anytime, thanks for your reviewing and comments.


2013/4/26 Peng Fan <van.freenix at gmail.com>

> Hi,
>
> 1.
> I modified the ABS32 TYPE of arm, as listed below:
> diff --git a/rtl-mdreloc-arm.c b/rtl-mdreloc-arm.c
> index f31d1ef..f3f2680 100644
> --- a/rtl-mdreloc-arm.c
> +++ b/rtl-mdreloc-arm.c
> @@ -144,10 +144,10 @@ rtems_rtl_elf_relocate_rel (const rtems_rtl_obj_t*
>    obj,
>  #endif
>  #endif
>
> - case R_TYPE(ABS32): /* word32 B + S + A */
> - case R_TYPE(GLOB_DAT): /* word32 B + S */
> + case R_TYPE(ABS32): /* word32 (S + A) | T */
> + case R_TYPE(GLOB_DAT): /* word32 (S + A) | T */
>   if (__predict_true(RELOC_ALIGNED_P(where))) {
> - tmp = *where + (Elf_Addr)sect->base + symvalue;
> + tmp = *where + symvalue; /* S + A*/
>   /* Set the Thumb bit, if needed.  */
>   if (ELF_ST_TYPE(syminfo) == STT_ARM_TFUNC)
> Now, x.rap can work all ok.
>
> 2. questions about dumplicated symbols
> #rap ld ./x.rap
> ./x.rap loaded
> #cp x.rap b.rap
> #rap ld ./b.rap
> #./b.rap loaded
> [/] # rap ls
>  App        DL Handle  Name
>  0x50582fb8 0x505904a0 ./x.rap
>  0x50596ce0 0x505904a0 ./b.rap
>
> Is it ok for this?b.rap and x.rap have the same symbols.
> It seems b.rap and x.rap both have their local "global_symbols" and share
> the rtems kernel image symbols. I am not sure about this.
>
> rtems_rtl_match_name is used to match whether this rap is loaded or not,
> but I think  there maybe something wrong with it.
> bool rtems_rtl_match_name (rtems_rtl_obj_t* obj, const char* name)
> {
>   const char* n1 = obj->oname;
>   while ((*n1 != '\0') && (*n1 != '\n') && (*n1 != '/') &&
>          (*name != '\0') && (*name != '/') && (*n1 == *name))
>   {
>     ++n1;
>     ++name;
>   }
>   if (((*n1 == '\0') || (*n1 == '\n') || (*n1 == '/')) &&
>       ((*name == '\0') || (*name == '/')))
>     return true;  *//It always return true if "rap ld ./x.rap or rap ld
> ./y.rap"*
>   return false;
> }
>
> I have an idea. each loaded rap file symbol table is chained in a list,
> and the rap file
> which will be loaded should first search the list to decide which symbol
> is needed to reloaced and which was already relocated in the list. And also
> the match name method should be corrected.
>
> Thanks in advance for your comments.
>
>
> 3.
> I am reading the linker code now, and have a few questions about the host
> side.
> About "extend the RTEMS linker to support a new option that instructs it
> to place  object files from ELF archives into a RAP format archive file"
>
> I think there maybe some same points with label '2' to avoid dumplicated
> symbols.But I am not sure.
>
> a single elf relocated object file is converted to a rap format file. At
> last all the rap format files is archived in to an archive file. The
> runtime loader should be capable to handle the rap archive file. And the
> purpose of introducing rap archive file  is to avoid dumplicated symbols.
> Is this right?
>
> 4. About the new tool
> I was trying to figure out how the linker works.And now have a basic
> knowledge of it.
> But I do not know the significance of the new tool. Is the new tool is
> used to convert one elf file to one rap format file?Hope you can give me
> some advice about this point.
>
> Thanks.
>
> Regards,
> Peng.
>
>
> 2013/4/23 Chris Johns <chrisj at rtems.org>
>
>> Peng Fan wrote:
>>
>>>     I have tested x.rap on Tiny6410 board. It works now.
>>>     The patch is listed in https://gist.github.com/MrVan/**5440197<https://gist.github.com/MrVan/5440197>
>>>
>>
>> Thanks for this. It is excellent work. I have reviewed the patch and I
>> will take off line what I need from you to get the changes merged.
>>
>> Chris
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130504/1ef65470/attachment.html>