[GSOC2013] Dynamic object file loading

Fri Apr 19 12:32:15 UTC 2013

The tar version issue sounds like a bug.  We should try to isolate just the
version problem to see if it is easy to reproduce, then file a bug report.
On Apr 19, 2013 3:23 AM, "Peng Fan" <van.freenix at gmail.com> wrote:

> 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
>
> #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.
>
> 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.
>
>
>
>>
>>> 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.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130419/3de790f4/attachment.html>