Simple question about RTL

[Pavel Pisa]

Hello Tim Tian,


On Friday 26 of August 2016 10:24:55 xuelin.tian at qkmtech.com wrote:
> I follow the instructions which Pavel Pisa posted online.
> https://lists.rtems.org/pipermail/devel/2016-July/015683.html
> But, when I go to the "prelink generation" step, which is
> "arm-rtems4.11-gcc ${CFLAGS1} -Wl,--gc-sections init.o rootfs_tarfile.o -lm
> -o appdl.prelink", some error came up, #/.../ld: failed to merge target
> specific data of file init.o

You should post the messages before this final error.

I expect that your problem is that object file generated by
objdump has incompatible ARM ABI compiled in (even that there
is in the fact no code in binary data)

You can try to skip check in the final link by adding

   -Wl,--accept-unknown-input-arch

to GCC command line or 

   --accept-unknown-input-arch

if bare LD is used.

My sequence is

  arm-rtems4.12-ld -r --accept-unknown-input-arch -b binary -o rootfs_tarfile.o.tmp rootfs_tarfile
  arm-rtems4.12-objcopy --rename-section .data=.rodata,alloc,load,readonly,data,contents rootfs_tarfile.o.tmp rootfs_tarfile.o

Do you use the output of the second step for final linking. The first step of binary
to object conversion (rootfs_tarfile.o.tmp) is holds default architecture
variant flags which is incompatible with most other ARM targets.

The second step with objcopy removes these sections.

If you use bigendian ARM target then default is little endian
and this cannot be merged at all. The arm-rtems4.12-ld -r requires
to add "-EB" option. I oversside that in OMK hackish way for now
and need to solve that better

$(2).o: $(2)
        @$(QUIET_CMD_ECHO) "  TARFILE $$@"
-       $(Q) $(LD) -r --accept-unknown-input-arch -b binary -o $$@.tmp $$^
+       $(Q) $(LD) -EB -r --accept-unknown-input-arch -b binary -o $$@.tmp $$^
        $(Q) $(OBJCOPY) --rename-section .data=.rodata,alloc,load,readonly,data,contents $$@.tmp $$@


Best wishes,

                Pavel


> #/.../ld: warning: cannot find entry symbol _start; defaulting to
> 0000000000008000 #collect2: error: ld returned 1 exit status
>
> And he did not use rtems-ld to generate any file, so I got a little
> confused. Any idea?
>
> Later, I also tried to use rtems-ld to link init.o and rootfs_tarfile.o,
> and it said: #resolver:resolving: undefines, unresolved: 1
> #resolver:resolve: |- rtems
> #error: undefines: symbol not found: rtems
> Here, I just want to know what '-b' the base kernel is, an object file
> (after compile before link), or an .exe (after statically link)? Thanks.

>
>
> Best wishes,
> Tim Tian
> xuelin.tian at qkmtech.com
>
> From: Chris Johns
> Date: 2016-08-25 13:30
> To: xuelin.tian at qkmtech.com; users at rtems.org
> Subject: Re: Simple question about RTL
>
> On 25/08/2016 1:02 PM, xuelin.tian at qkmtech.com wrote:
> > Hi Chris,
> > thanks for you reply. I'm trying to understand the concept here, and
> > some points are still confusing me.
> > In general, linking process should happen before applications taking
> > control of CPU, which means the OS should handle the linking process.
>
> The RTL provides a run-time link editor which allows you to load code
> with-in your running application. Libdl is the link editor. It is you or
> your code that tells it what to do.
>
> > In
> > RTEMS, the Init task should take care of this, am I right?
>
> The Init task is your 'main' so this is your code. You are free to
> structure how you manage this just like any other part of your application.
>
> > Now, for example, I have one base kernel and one tar file. My base
> > kernel is running on my target (ZedBoard), and how can I load the tar
> > file into memory using shell command via Jtag?
>
> For an engineering development environment I would enable networking
> using libbsd and then NFS mount an exported disk from a host on the
> network. I would place the ELF object files where you can see them from
> the Zedboard and then use the RTL command to load the code.
>
> Chris