[GSOC2013] Dynamic object file loading

[Peng Fan]

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

> Hi,
>
> 2013/4/19 Chris Johns <chrisj at rtems.org>
>
>> Peng Fan wrote:
>>
>>>
>>>     There are symbols in main.c that understand the tar file. Is
>>>     something wrong with them ?
>>>
>>>   I looked insight into the code and found that
>>>   the fs-root.tar is untared by setup_rootfs->Untar_**FromMemory.
>>>   Is it becasue the tar version on my host pc does not match Untar_* in
>>> RTEMS?
>>>   I follow the compilation log to clarify how waf works and how
>>> fs-root.tar is compiled into rtld.look at the following:
>>> 1. shell-init libx.a -> fs-root.tar -> fs-root-tarfile.o
>>>
>>
>> Yes using objcopy.
>>
>>
>>  2. init.c.5.o main.c.5.o fs-root-tarfile.o -lrtl -> rtld.prelink
>>>
>>
>> Link it together.
>>
>>
>>  3. nm rtld.prelink -> rtld-gsyms.c
>>>
>>
>> Get the symbols present in the base image.
>>
>>
>>  4. init.c main.c rtld-gsyms.c xa.c x-long-name...-in-archive.c
>>>    -> x.rap
>>>
>>
>> Create the RAP app.
>>
>>
>>  5. shell-init libx.a x.rap -> fs-root.tar -> fs-root-tarfile.o
>>>
>>
>> Build the tar file.
>>
>>
>>  6. init.c.10.o main.c.10.o fs-root-tarfile.o  rtld-gsyms.10.o -lrtl ->
>>> rtld
>>>
>>
>> Relink with the symbol table generated so the base image has its own
>> symbol table.
>>
>>
>>  I also objdump the code to see if any address is wrong, but all is ok.
>>> Now what I doubt is only verison mismatch.
>>>
>>
>> Great.
>>
>> Thanks for your encouragement. All is challenging and interesting.
>
> I have resovled the "shell: open input /shell-init failed: No such file
> or directory" problem. The version mismatch between my host(Opensuse with
> tar 1.26) and rtems Untar_*.
>
> The code in Untar_FromMemory use the first 512 block as the header.It is
> right indeed. But it does not judge the linkflag whether it is extened or
> others, and this incurs error. The GNU tar 1.26:
> http://www.gnu.org/software/tar/manual/html_node/Standard.html gives the
> details
>
>
sorry,512 should be 512 bytes.

> #define XHDTYPE 'x' /* Extended header referring to the next file in the
> archive */
>
> #define XGLTYPE  'g'            /* Global extended header */
>
> If linkflag is XHDTYPE, we should reconsider how to process the header,because
>
> 'x' means an extened header after the first begin header in which file_size is not the size of the size but the extened header.
>
> sorry, file_size of not the size of the file but the extended header.

> I use a simple way, under the original header processing code, adding the following code :
>
>
>  ptr += 512; //jump to the real header containing the size info of the file in tarball.
>
>  if (linkflag == 'x') { //here is really a simple way, because there are many other flags.
>
>  bufr = &tar_ptr[ptr];
>
>  strncpy(fname, bufr, MAX_NAME_FIELD_SIZE);
>
>  fname[MAX_NAME_FIELD_SIZE] = '\0';
>
>  linkflag   = bufr[156];
>
>  file_size  = _rtems_octal2ulong(&bufr[124], 12);
>
>  ptr += 512;
>
>  hdr_chksum = _rtems_octal2ulong(&bufr[148], 8);
>
>  sum = _rtems_tar_header_checksum(bufr);
>
>  if (sum != hdr_chksum)
>       {
>
>  retval = UNTAR_INVALID_CHECKSUM;
>
>  break;
>
>  }
>
>  }
>
> I do not know whether this is a bug for RTEMS or not.
>
> 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)""
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.

When debugging dlopen returns sucessfully, but "init = dlsym (app->handle, "
*rtems*");" returns with "init=NULL".Thus rap load failed.

In dlsym, It first try find the symbol in it's local "global_table". 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.

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".

Thanks.

>
>>
>>> A question that I want your answer, is the rtld.prelink only used for
>>> generating rtld-gsymcs.c? I think it is, but not sure.
>>>
>>>
>> Yes. You need to perform a link so the needed symbols are pulled into the
>> kernel. Once you have these symbols you can generate a symbol table and
>> then relink. The original base image has a weak symbol which is overridden
>> with the real symbol table.
>>
>>
>>> When modified the rtems.py with "d.endswith('-rtems*eabi*' + version)",
>>>
>>
>> The RTEMS tools are arm-rtems4.11. As far as I know there is no need for
>> 'eabi' to be present in the tools any more.
>>
>>
>>  It tells "error: libelf:elf_getdata: .ARM.attributes(xa.c.8.o): Invalid
>>> section descriptor"
>>>
>>
>> This is the bug.
>>
>>
>>  I may dig into rtl-host code to figure out why and this may be part of
>>> the work that I should focus on
>>>
>>
>> Thanks. It will be in the ELF section parsing somewhere.
>>
>>
>>      The project need work to implement more architectures. I am
>>>     traveling at the moment and will be back later in the week. A
>>>     proposal to work on these other archs would be welcome.
>>>
>>> I want to implement arm support first. If time permits, I will implement
>>> mips too.
>>> Now I can not evaluate the workload whether I can finish one, two or
>>> more. I am preparing the proposal and it'll be finished soon.
>>>
>>
>> Great.
>
> Thanks
>
>>
>>
>> Chris
>>
>
> Regards,
> Peng.
>

Regards,
Peng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130419/de499ac4/attachment-0001.html>