[GSOC2013] Dynamic object file loading

[Joel Sherrill]

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<mailto: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<mailto:van.freenix at gmail.com>> wrote:
Hi,

2013/4/19 Chris Johns <chrisj at rtems.org<mailto: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<mailto: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/af788a90/attachment-0001.html>