[GSOC2013] Dynamic object file loading

[Peng Fan]

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/20130426/ea686009/attachment-0001.html>