[GSOC2013] Dynamic object file loading

[Peng Fan]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130419/57a51077/attachment-0001.html>