[GSOC2013] Dynamic object file loading

[Peng Fan]

Hi,

I add the following code to ignore ARM.attributes and ARM.exidx sections
which are contained in xa.c x-long.*.c and rtld.prelink. Not sure whether
this is right or not, but when compling rtl target, all is passed. This may
looks
not a good way.
diff --git a/elftoolchain/libelf/elf_data.c b/elftoolchain/libelf/elf_data.c
index 5ac6453..a6e17ae 100644
--- a/elftoolchain/libelf/elf_data.c
+++ b/elftoolchain/libelf/elf_data.c
@@ -87,9 +87,20 @@ elf_getdata(Elf_Scn *s, Elf_Data *d)
  return (NULL);
  }

+ if (sh_type == 0x70000003 || sh_type == 0x70000001) {
+ if ((d = _libelf_allocate_data(s)) == NULL)
+ return (NULL);
+  d->d_buf = 0;
+  d->d_size = 0;
+ return (d);
+ }
+  //printf("freenix %x %x\n", (sh_type), ELF_T_FIRST);
+

Now, I am trying to make the rtld run on my Tiny6410 board. It does run,
but rap load ./x.rap fails. Error msg is:
rtl: reloc unknown: sym = 0, type = 29, offset = 0x4, contents = 0xeafffffe
error: loading: (22) .text: Unsupported relocation type 29 in non-PLT
relocations

Type 29 in elf for arm is R_TYPE_JUMP24 which is not supported in
rtl-target side, thus error occurs. I am trying to add this to target side.

I have finished a proposal draft. It is
here<https://docs.google.com/document/d/1HBkRU7_kUOvoiCQWTUxQ151kvX--3x_E7r0rTerxYbo/edit?usp=sharing>.
You can edit it. Hope you can give me some suggestions. On the target side,
I know the main work that I should done is in rtl-mdreloc-arm.c, but on the
host side, It seems all have been done.  Thnnks.

Regards,
Peng.




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

> It works when I add a 'int rtems(int argc, char **argv)' function. Thanks.
>
>
> 2013/4/20 Chris Johns <chrisj at rtems.org>
>
>> Peng Fan wrote:
>>
>>>
>>>     Added the code, I can see the three files: libx.a shell-init  x.rap
>>>
>>>     Here appears another problem:
>>>
>>>     When"rap ld ./x.rap", it tells"error: loading: (0)"
>>>
>>>     When"dlo x.rap","error: duplicate global symbol: hello". However,
>>>  dlo libx.a:xa.c.1.o and dlo libx.a:x-long-name-to-create-**gnu-extension-in-archive.c.1.o
>>> is ok.
>>>
>>>
>>> Tried to find why "When "rap ld ./x.rap", it tells "error: loading: (0)""
>>>
>>
>> Did you grep for the string and set a break point in it and then look at
>> the back trace ? This is a pretty bad error message. Something is wrong
>> here.
>>
>>
>>  I trace rtld using sparc-rtems4.11-gdb.
>>> In rap.c, there are two functions to do the loading ,linking and finding
>>> symbol job, dlopen foucsing on loading and resolving symbols, while
>>> dlsym returns the symbol address.
>>>
>>
>> Correct.
>>
>>  When debugging dlopen returns sucessfully, but "init = dlsym
>>> (app->handle, "*rtems*");" returns with "init=NULL".Thus rap load failed.
>>>
>>
>> What is "*rtems*" ? Wild cards will not work.
>>
>>
>>  In dlsym, It first try find the symbol in it's local "global_table".
>>>
>>
>> Correct.
>>
>>  In
>>> x.rap, It's global_table includes "hello", "w_writeln" ,"x_writeln",
>>> "y_writeln", "z_writeln", "public", "my_main". with no one matches
>>> "*rtems*". Then It tries to find the symbol in global symbol which maybe
>>>
>>> generated in rtld-gsyms.c using a hash method.However, it still can not
>>> find the    match "rtems" symbol. Thus, failed.
>>>
>>
>> Oh ok I get what is happening, yes this is correct. The symbols is
>> 'rtems' and it is a kind of 'main' for the RTEMS application. It is nothing
>> more than that. The x.rap is a progression and I ended up testing the whole
>> think with a waf based libbsdports that create a RAP image. I need to get
>> this out onto a server somewhere.
>>
>>
>>
>>> I do not know the "rtems" symbol means what. I see it is assigned to
>>> init, and then init(*, *). I am confusing  about why "rtems".
>>>
>>>
>> This is understandable because I failed to add the reason to the doco. As
>> I said this is an RTEMS Application's main. I did not want to use main
>> because this has a well known and understood use.
>>
>> Well done on getting this far. If you add an 'rtems' function to the
>> x.rap and have it print something the load should work.
>>
>> Chris
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130422/271a86c5/attachment-0001.html>