Bug 1075

To clarify. The device when booted it using glibc dynamic linker and boots into busybox using that.  You copy the uclibc binary and the required shared libraries
to device and then you execute the binary and it segfaults.

If thats the case is it possible for you to boot into uclibc based root file system and see if this happens there too. 

Sounds much like a duplicate of bug #1033. Do you have DOPIC set in your .config? Please attach it here.

thanks,

Created attachment 1219 [details]
.config file used

Bernhard: the .config file contains DOPIC=y. Please find it attached.

Raj: I created a new ramdisk with no glibc at all, only uClibc. The dynamically linked programs fail to start. If init is dynamically linked the kernel panics. If init is statically linked and does execve on a dynamically linked program, the call fails with "No such file or directory"

you are compiling uclibc with oabi. Do you have oabi support in kernel ?

I compiled uClibc with EABI and OABI, and the program linked to it crashes at the same point in both cases

(In reply to comment #5)
> I compiled uClibc with EABI and OABI, and the program linked to it crashes at
> the same point in both cases

please try current master, we can try to debug it there.

Pulled from git master today, same problem

Apparently not many people are experiencing this, so, in perfect open-source fashion, I'm on my own.

Yet, my knowledge of uClibc is not deep enough to thoroughly analyse the problem. I did some investigation, though.

The crash occurs when _dl_app_init_array() calls _dl_run_init_array() passing _dl_loaded_modules as argument. That is in ldso/ldso/dl-array.c, and just dereferences the tpnt pointer pased as argument and calls _dl_run_array_forward. Most probably the compiler inlines _dl_run_array_forward. 

The crash seems due to the fact that _dl_loaded_modules is NULL, and _dl_run_init_array tries to dereference it.

For what I could see, in order for _dl_loaded_modules to be initialised, _dl_get_ready_to_run must be called. And _dl_get_ready_to_run is never called.

Only, my knowledge of uClibc is too limited to go further, so I'd like to have help from experts about those 2 questions:
1. is the above correct?
2. when is _dl_get_ready_to_run supposed to be called?

Thank you in advance

A little more investigation.

fge:~/crosscompiling/uClibc/lib$ arm-linux-objdump -f libuClibc-0.9.32-rc2-git.so 

libuClibc-0.9.32-rc2-git.so:     file format elf32-littlearm
architecture: arm, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000078e0

fge@WX800170:~/crosscompiling/uClibc/lib$ arm-linux-objdump -h libuClibc-0.9.32-rc2-git.so 

libuClibc-0.9.32-rc2-git.so:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .hash         000016ec  00000114  00000114  00000114  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00003b00  00001800  00001800  00001800  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       00002096  00005300  00005300  00005300  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .rel.dyn      00000300  00007398  00007398  00007398  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rel.plt      000000e0  00007698  00007698  00007698  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .plt          00000164  00007778  00007778  00007778  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .text         000256a0  000078e0  000078e0  000078e0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  7 .rodata       000029fd  0002cf80  0002cf80  0002cf80  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .interp       00000030  0002f980  0002f980  0002f980  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .data.rel.ro  000000ec  00037e6c  00037e6c  0002fe6c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .dynamic      000000a8  00037f58  00037f58  0002ff58  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .got          000000f4  00038000  00038000  00030000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .data         00000198  000380f4  000380f4  000300f4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 13 .bss          00003d90  0003828c  0003828c  0003028c  2**2
                  ALLOC
 14 .ARM.attributes 00000010  00000000  00000000  0003028c  2**0
                  CONTENTS, READONLY
 15 .gnu.warning.gets 0000003c  00000000  00000000  0003029c  2**2
                  CONTENTS, READONLY
 16 .gnu.warning.tmpnam 00000038  00000000  00000000  000302d8  2**2
                  CONTENTS, READONLY
 17 .gnu.warning.gethostbyaddr_r 0000003c  00000000  00000000  00030310  2**2
                  CONTENTS, READONLY
 18 .gnu.warning.gethostbyname_r 0000003c  00000000  00000000  0003034c  2**2
                  CONTENTS, READONLY
 19 .gnu.warning.gethostbyaddr 0000003c  00000000  00000000  00030388  2**2
                  CONTENTS, READONLY
 20 .gnu.warning.gethostbyname 0000003c  00000000  00000000  000303c4  2**2
                  CONTENTS, READONLY
 21 .gnu.warning.siggetmask 0000003c  00000000  00000000  00030400  2**2
                  CONTENTS, READONLY
 22 .comment      00000011  00000000  00000000  0003043c  2**0
                  CONTENTS, READONLY

Summary: the start address is just the start of .text section. This may or may not be right, but feels wrong...

fge:~/crosscompiling/uClibc/lib$ arm-linux-objdump -T libuClibc-0.9.32-rc2-git.so |grep 78e0
000078e0 l    d  .text	00000000 .text
000078e0 g    DF .text	00000048 brk

It is as if the startup function is brk(). Maybe DL_START() should be called instead?