[GSOC2013] Dynamic object file loading

Fri Apr 19 12:43:21 UTC 2013

Hi Gedare,

I think the newest tar version 1.26 on linux may mismatch with rtems.
I am not sure whether some tar command options may generate matching
tarballs,
but I failed with trying "--posix"
I "hexdump -C *.tar" and find it does include extened header, while RTEMS
does not handle this.

2013/4/19 Gedare Bloom <gedare at gwmail.gwu.edu>

> 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/5ffc00e1/attachment-0001.html>