[GSOC2013] Dynamic object file loading

Fri Apr 19 14:35:27 UTC 2013

I have got a wrong side on this tar related problem.
Take a detour.

When using "tar --format=gnu -cf fs-root.tar shell-init libx.a x.rap" , the
fs-root.tar can be handled by RTEMS. If omit the "--format=gnu", RTEMS will
not handle it sucessfully.

2013/4/19 Joel Sherrill <Joel.Sherrill at oarcorp.com>

>  What does the unsupported type do?
>
> Is it something that needs to be supported?
>
> Is it an addition to POSIX tar or a bug?
>
> Will this need to be supported by the tarFS?
>
> Sorry to have questions and no answers. :(
>
> --joel
>
> Peng Fan <van.freenix at gmail.com> wrote:
>
>
>  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/48d1a6a3/attachment-0001.html>