<div dir="ltr">Hi,<div><br><div style>It's default format is compatible with POSIX 1003.1-2001(pax) format.</div><div style>I have tried all other formats listed in tar options.</div><div style>--format = gnu     GNU tar 1.13.x format</div>
<div style>               oldgnu tar < 1.12</div><div style>               pax     POSIX 1003.1-2001 (pax) format</div><div style>               posix  same as pax</div><div style>               ustar   POSIX 1003.1-1988 (ustar) format</div>
<div style>               v7       old V7 tar format</div><div style>posix and v7 format are not supported in RTEMS. Others are ok.</div><div style>The pax format can be found here:<a href="http://cs.unomaha.edu/~stanw/POSIX/01309816.pdf">http://cs.unomaha.edu/~stanw/POSIX/01309816.pdf</a> page 712. The ustar format can be handled by RTEMS. If want to be compatible with newer posix version, I think something should be done in untar related functions. </div>
<div style><br></div><div style>Regards,</div><div style>Peng.</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/19 Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwmail.gwu.edu" target="_blank">gedare@gwmail.gwu.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please find out what the default format is, and whether we should do<br>
something to support it in our implementation of the<br>
cpukit/libmisc/untar functions.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Apr 19, 2013 at 10:35 AM, Peng Fan <<a href="mailto:van.freenix@gmail.com">van.freenix@gmail.com</a>> wrote:<br>
> I have got a wrong side on this tar related problem.<br>
> Take a detour.<br>
><br>
> When using "tar --format=gnu -cf fs-root.tar shell-init libx.a x.rap" , the<br>
> fs-root.tar can be handled by RTEMS. If omit the "--format=gnu", RTEMS will<br>
> not handle it sucessfully.<br>
><br>
><br>
><br>
> 2013/4/19 Joel Sherrill <<a href="mailto:Joel.Sherrill@oarcorp.com">Joel.Sherrill@oarcorp.com</a>><br>
>><br>
>> What does the unsupported type do?<br>
>><br>
>> Is it something that needs to be supported?<br>
>><br>
>> Is it an addition to POSIX tar or a bug?<br>
>><br>
>> Will this need to be supported by the tarFS?<br>
>><br>
>> Sorry to have questions and no answers. :(<br>
>><br>
>> --joel<br>
>><br>
>> Peng Fan <<a href="mailto:van.freenix@gmail.com">van.freenix@gmail.com</a>> wrote:<br>
>><br>
>> Hi Gedare,<br>
>><br>
>> I think the newest tar version 1.26 on linux may mismatch with rtems.<br>
>> I am not sure whether some tar command options may generate matching<br>
>> tarballs,<br>
>> but I failed with trying "--posix"<br>
>> I "hexdump -C *.tar" and find it does include extened header, while RTEMS<br>
>> does not handle this.<br>
>><br>
>><br>
>> 2013/4/19 Gedare Bloom <<a href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a>><br>
>>><br>
>>> The tar version issue sounds like a bug.  We should try to isolate just<br>
>>> the version problem to see if it is easy to reproduce, then file a bug<br>
>>> report.<br>
>>><br>
>>> On Apr 19, 2013 3:23 AM, "Peng Fan" <<a href="mailto:van.freenix@gmail.com">van.freenix@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> 2013/4/19 Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
>>>>><br>
>>>>> Peng Fan wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>>     There are symbols in main.c that understand the tar file. Is<br>
>>>>>>     something wrong with them ?<br>
>>>>>><br>
>>>>>>   I looked insight into the code and found that<br>
>>>>>>   the fs-root.tar is untared by setup_rootfs->Untar_FromMemory.<br>
>>>>>>   Is it becasue the tar version on my host pc does not match Untar_*<br>
>>>>>> in<br>
>>>>>> RTEMS?<br>
>>>>>>   I follow the compilation log to clarify how waf works and how<br>
>>>>>> fs-root.tar is compiled into rtld.look at the following:<br>
>>>>>> 1. shell-init libx.a -> fs-root.tar -> fs-root-tarfile.o<br>
>>>>><br>
>>>>><br>
>>>>> Yes using objcopy.<br>
>>>>><br>
>>>>><br>
>>>>>> 2. init.c.5.o main.c.5.o fs-root-tarfile.o -lrtl -> rtld.prelink<br>
>>>>><br>
>>>>><br>
>>>>> Link it together.<br>
>>>>><br>
>>>>><br>
>>>>>> 3. nm rtld.prelink -> rtld-gsyms.c<br>
>>>>><br>
>>>>><br>
>>>>> Get the symbols present in the base image.<br>
>>>>><br>
>>>>><br>
>>>>>> 4. init.c main.c rtld-gsyms.c xa.c x-long-name...-in-archive.c<br>
>>>>>>    -> x.rap<br>
>>>>><br>
>>>>><br>
>>>>> Create the RAP app.<br>
>>>>><br>
>>>>><br>
>>>>>> 5. shell-init libx.a x.rap -> fs-root.tar -> fs-root-tarfile.o<br>
>>>>><br>
>>>>><br>
>>>>> Build the tar file.<br>
>>>>><br>
>>>>><br>
>>>>>> 6. init.c.10.o main.c.10.o fs-root-tarfile.o  rtld-gsyms.10.o -lrtl -><br>
>>>>>> rtld<br>
>>>>><br>
>>>>><br>
>>>>> Relink with the symbol table generated so the base image has its own<br>
>>>>> symbol table.<br>
>>>>><br>
>>>>><br>
>>>>>> I also objdump the code to see if any address is wrong, but all is ok.<br>
>>>>>> Now what I doubt is only verison mismatch.<br>
>>>>><br>
>>>>><br>
>>>>> Great.<br>
>>>>><br>
>>>> Thanks for your encouragement. All is challenging and interesting.<br>
>>>><br>
>>>> I have resovled the "shell: open input /shell-init failed: No such file<br>
>>>> or directory" problem. The version mismatch between my host(Opensuse with<br>
>>>> tar 1.26) and rtems Untar_*.<br>
>>>><br>
>>>> The code in Untar_FromMemory use the first 512 block as the header.It is<br>
>>>> right indeed. But it does not judge the linkflag whether it is extened or<br>
>>>> others, and this incurs error. The GNU tar<br>
>>>> 1.26:<a href="http://www.gnu.org/software/tar/manual/html_node/Standard.html" target="_blank">http://www.gnu.org/software/tar/manual/html_node/Standard.html</a> gives<br>
>>>> the details<br>
>>>><br>
>>>> #define XHDTYPE 'x' /* Extended header referring to the next file in the<br>
>>>> archive */<br>
>>>><br>
>>>> #define XGLTYPE  'g'            /* Global extended header */<br>
>>>><br>
>>>> If linkflag is XHDTYPE, we should reconsider how to process the<br>
>>>> header,because<br>
>>>><br>
>>>> 'x' means an extened header after the first begin header in which<br>
>>>> file_size is not the size of the size but the extened header.<br>
>>>><br>
>>>> I use a simple way, under the original header processing code, adding<br>
>>>> the following code :<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>>  ptr += 512; //jump to the real header containing the size info of the<br>
>>>> file in tarball.<br>
>>>><br>
>>>>  if (linkflag == 'x') { //here is really a simple way, because there are<br>
>>>> many other flags.<br>
>>>><br>
>>>>  bufr = &tar_ptr[ptr];<br>
>>>><br>
>>>>  strncpy(fname, bufr, MAX_NAME_FIELD_SIZE);<br>
>>>><br>
>>>>  fname[MAX_NAME_FIELD_SIZE] = '\0';<br>
>>>><br>
>>>>  linkflag   = bufr[156];<br>
>>>><br>
>>>>  file_size  = _rtems_octal2ulong(&bufr[124], 12);<br>
>>>><br>
>>>>  ptr += 512;<br>
>>>><br>
>>>>  hdr_chksum = _rtems_octal2ulong(&bufr[148], 8);<br>
>>>><br>
>>>>  sum = _rtems_tar_header_checksum(bufr);<br>
>>>><br>
>>>>  if (sum != hdr_chksum)<br>
>>>>       {<br>
>>>><br>
>>>>  retval = UNTAR_INVALID_CHECKSUM;<br>
>>>><br>
>>>>  break;<br>
>>>><br>
>>>>  }<br>
>>>><br>
>>>>  }<br>
>>>><br>
>>>> I do not know whether this is a bug for RTEMS or not.<br>
>>>><br>
>>>> Added the code, I can see the three files: libx.a shell-init  x.rap<br>
>>>><br>
>>>> Here appears another problem:<br>
>>>><br>
>>>> When "rap ld ./x.rap", it tells "error: loading: (0)"<br>
>>>><br>
>>>> When "dlo x.rap", "error: duplicate global symbol: hello". However, dlo<br>
>>>> libx.a:xa.c.1.o and dlo<br>
>>>> libx.a:x-long-name-to-create-gnu-extension-in-archive.c.1.o is ok.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>>><br>
>>>>>> A question that I want your answer, is the rtld.prelink only used for<br>
>>>>>> generating rtld-gsymcs.c? I think it is, but not sure.<br>
>>>>>><br>
>>>>><br>
>>>>> Yes. You need to perform a link so the needed symbols are pulled into<br>
>>>>> the kernel. Once you have these symbols you can generate a symbol table and<br>
>>>>> then relink. The original base image has a weak symbol which is overridden<br>
>>>>> with the real symbol table.<br>
>>>>><br>
>>>>>><br>
>>>>>> When modified the rtems.py with "d.endswith('-rtems*eabi*' +<br>
>>>>>> version)",<br>
>>>>><br>
>>>>><br>
>>>>> The RTEMS tools are arm-rtems4.11. As far as I know there is no need<br>
>>>>> for 'eabi' to be present in the tools any more.<br>
>>>>><br>
>>>>><br>
>>>>>> It tells "error: libelf:elf_getdata: .ARM.attributes(xa.c.8.o):<br>
>>>>>> Invalid<br>
>>>>>> section descriptor"<br>
>>>>><br>
>>>>><br>
>>>>> This is the bug.<br>
>>>>><br>
>>>>><br>
>>>>>> I may dig into rtl-host code to figure out why and this may be part of<br>
>>>>>> the work that I should focus on<br>
>>>>><br>
>>>>><br>
>>>>> Thanks. It will be in the ELF section parsing somewhere.<br>
>>>>><br>
>>>>><br>
>>>>>>     The project need work to implement more architectures. I am<br>
>>>>>>     traveling at the moment and will be back later in the week. A<br>
>>>>>>     proposal to work on these other archs would be welcome.<br>
>>>>>><br>
>>>>>> I want to implement arm support first. If time permits, I will<br>
>>>>>> implement<br>
>>>>>> mips too.<br>
>>>>>> Now I can not evaluate the workload whether I can finish one, two or<br>
>>>>>> more. I am preparing the proposal and it'll be finished soon.<br>
>>>>><br>
>>>>><br>
>>>>> Great.<br>
>>>><br>
>>>> Thanks<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Chris<br>
>>>><br>
>>>><br>
>>>> Regards,<br>
>>>> Peng.<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> rtems-devel mailing list<br>
>>>> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
>>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
>>>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>