[GSOC2013] Dynamic object file loading
Peng Fan
van.freenix at gmail.com
Sat Apr 20 03:55:46 UTC 2013
Hi,
It's default format is compatible with POSIX 1003.1-2001(pax) format.
I have tried all other formats listed in tar options.
--format = gnu GNU tar 1.13.x format
oldgnu tar < 1.12
pax POSIX 1003.1-2001 (pax) format
posix same as pax
ustar POSIX 1003.1-1988 (ustar) format
v7 old V7 tar format
posix and v7 format are not supported in RTEMS. Others are ok.
The pax format can be found here:
http://cs.unomaha.edu/~stanw/POSIX/01309816.pdf 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.
Regards,
Peng.
2013/4/19 Gedare Bloom <gedare at gwmail.gwu.edu>
> Please find out what the default format is, and whether we should do
> something to support it in our implementation of the
> cpukit/libmisc/untar functions.
>
> On Fri, Apr 19, 2013 at 10:35 AM, Peng Fan <van.freenix at gmail.com> wrote:
> > 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.htmlgives
> >>>> 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/20130420/2ab832a4/attachment-0001.html>
More information about the devel
mailing list