No subject

Mon Mar 17 22:01:46 UTC 2008

Command line used to build your application. Source code if available.
Further I suggest you to build with debug synmbol (both your application
and uclibc) and start using gdb to debug.
The info you provide are not enough to figure out what is going wrong 

 kannappan - 02-22-08 00:06  
The problem happens when -lpthread is used along with -lc.

for example:

# arm-linux-gcc -lc -lpthread sample.c 

The strace for this attached.

The same program works when i compile with
# arm-linux-gcc -lpthread sample.c 

 carmelo73 - 02-22-08 00:13  
As a general suggestion, you don't need to link explicitly against libc
it is done by default by the compiler (append -v at your build command and
you will see what it is doing silently)
Further are you sure arm-linux-gcc is properly configured for uClibc ?
Could you post the output of the command readelf -l <executable> ? 

 vapier - 02-22-08 17:25  
straces are not terribly useful when talking about a threading crash

please post a source code test case which we can compile/debug 

 kannappan - 02-28-08 02:32  
Following is the output of readelf

[kans at localhost test]$ arm-linux-readelf -l a.out 

Elf file type is EXEC (Executable file)
Entry point 0x83ac
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00008034 0x00008034 0x000a0 0x000a0 R E 0x4
  INTERP         0x0000d4 0x000080d4 0x000080d4 0x00014 0x00014 R   0x1
      [Requesting program interpreter: /lib/]
  LOAD           0x000000 0x00008000 0x00008000 0x0050c 0x0050c R E
  LOAD           0x00050c 0x0001050c 0x0001050c 0x000ec 0x00108 RW 
  DYNAMIC        0x000518 0x00010518 0x00010518 0x000c0 0x000c0 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   01     .interp 
   02     .interp .hash .dynsym .dynstr .rel.plt .init .plt .text .fini
.rodata .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .data .bss 
   04     .dynamic 

Following are the output when compiled with -v option

Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with:
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibcgnueabi --enable-languages=c,c++
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--enable-shared --disable-nls --enable-threads --disable-multilib
Thread model: posix
gcc version 4.1.2

-quiet -v sample.c -quiet -dumpbase sample.c -mfloat-abi=soft -auxbase
sample -version -o /tmp/ccESRQ7x.s
ignoring nonexistent directory
#include "..." search starts here:
#include <...> search starts here:


End of search list.
GNU C version 4.1.2 (arm-linux-uclibcgnueabi)
        compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-8).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64298
Compiler executable checksum: 38e7075577afcde72725d9029281c4bb

-mfloat-abi=soft -meabi=4 -o /tmp/ccW0JqfY.o /tmp/ccESRQ7x.s

--eh-frame-hdr -dynamic-linker /lib/ -X -m armelf_linux_eabi
/tmp/ccW0JqfY.o -lpthread -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed

 xi - 03-26-08 14:55  
This is very similar to what I encountered with our MIPS toolchain and
NPTL. 0002414 might be the same problem too. 

I found one potential cause:

- Once libpthread is linked, standard loader is used instead of uClibc

Here is a console log showing this problem with ldd:

-o test testc.o
checking sub-depends for 'not found' => not found (0x00000000)
        <b>/lib/ => /lib/ (0x00000000)</b>

-o test testc.o –lpthread
checking sub-depends for '/lib/'
checking sub-depends for 'not found'
checking sub-depends for '/lib/' => /lib/ (0x00000000) => not found (0x00000000) => /lib/ (0x00000000)
        <b>/lib/ => /lib/ (0x00000000)</b>


 bla - 04-02-08 01:38  
I have the same issue on arm (nommu), uclibc 0.9.29. Using gdb on the
target I have tracked the problem down to the call to
__pthread_initialize_minimal during init. The call takes place via some
memory lookup, but ends up in the wrong place (somewhere in the data
segment). If I look at the target code with objdump -x I see this
disturbing fact:

00000000  w      *UND*  00000000 __pthread_initialize_minimal

So it's no wonder the call goes wrong, because the function code is not
included. It seems to me that something in the link process must have gone
wrong. The linker has clearly filled out the memory locations used in the
call with something, but forgot to include the actual code.

This is the part of the code where I see the failure (objdump -d):

00000898 <__GI___uClibc_init>:
     898:       e92d4010        stmdb   sp!, {r4, lr}
     89c:       e59f4054        ldr     r4, [pc,]   ; 8f8
     8a0:       e59f0054        ldr     r0, [pc,]   ; 8fc
     8a4:       e08f4004        add     r4, pc, r4
     8a8:       e7943000        ldr     r3, [r4, r0]
     8ac:       e3530000        cmp     r3,  ; 0x0
     8b0:       18bd8010        ldmneia sp!, {r4, pc}
     8b4:       e59f3044        ldr     r3, [pc,]   ; 900
     8b8:       e7941003        ldr     r1, [r4, r3]
     8bc:       e59f3040        ldr     r3, [pc,]   ; 904
     8c0:       e7942003        ldr     r2, [r4, r3]
     8c4:       e3a03001        mov     r3,  ; 0x1
     8c8:       e7843000        str     r3, [r4, r0]
     8cc:       e3510000        cmp     r1,  ; 0x0
     8d0:       e3a03a01        mov     r3,       ; 0x1000
     8d4:       e5823000        str     r3, [r2]
     8d8:       11a0e00f        movne   lr, pc
     8dc:       11a0f001        movne   pc, r1                    
<---------- FAILS HERE!!!
     8e0:       e59f3020        ldr     r3, [pc,]   ; 908
     8e4:       e0843003        add     r3, r4, r3
     8e8:       e3530000        cmp     r3,  ; 0x0
     8ec:       08bd8010        ldmeqia sp!, {r4, pc}
     8f0:       e8bd4010        ldmia   sp!, {r4, lr}
     8f4:       eafffe30        b       fffffa84 <_ebss+0xffffbaf4>
     8f8:       00001414        andeq   r1, r0, r4, lsl r4
     8fc:       000022b8        streqh  r2, [r0], -r8
     900:       0000002c        andeq   r0, r0, ip, lsr
     904:       00000044        andeq   r0, r0, r4, asr
     908:       ffffe4fc        undefined instruction 0xffffe4fc 

 hank_le - 04-03-08 10:09  
I am having a similar problem for an i586 target using uClibc-0.9.29,
binutils 2.18, and gcc 4.2.1.

I cross compile with the following :

export PATH_TO_BUILDROOT=/home/leinhos/src/buildroot
export LD=$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/bin/i586-linux-ld
export CPPFLAGS=-I$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/include
export LDFLAGS=-L$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/lib
export PATH=$PATH:$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/bin

and use the following makefile target line:

CFLAGS +=  -g -Wall
LIBS = -lpthread
OBJS =  ${SRCS:.c=.o}
vc_bridge: ${OBJS}
        ${CC} ${LIBS} -o $@ ${OBJS}

If I check the backtrace on the target, I see:

(gdb) set solib-absolute-prefix
(gdb) file vc_bridge
Reading symbols from /home/leinhos/src/vc_bridge-cvs/vc_bridge...done.
(gdb) target remote
Remote debugging using
warning: Remote failure reply: E01
0xb7f758b0 in _start () from
(gdb) cont

Program received signal SIGSEGV, Segmentation fault.
0xb7efc0a2 in memcpy () from
(gdb) bt  0xb7efc0a2 in memcpy () from
/home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/  0xb7f13ddc in __libc_pthread_init ()
/home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/  0xb7f647f8 in
__pthread_initialize_minimal ()
/home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/  0xb7f13ed9 in __uClibc_init () from
/home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/  0xb7f78393 in _dl_get_ready_to_run ()
/home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/  0xb7f786a0 in ?? () from
/home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/  0xbf94a590 in ?? ()  0xb7f75000 in ?? ()  0xbf94a674 in ?? ()  0xbf94a70c in ?? () 0xbf94a704 in ?? () 0xbf94a674 in ?? () 0xb7f75000 in ?? () 0x00000002 in ?? () 0x00000000 in ?? ()

I don't have any problems with applications compiled without pthreads.

compiling with the -v flag gives:

-v -g -Wall
-I/home/leinhos/src/buildroot/build_i586/staging_dir/usr/include  -c -o
vc_bridge.o vc_bridge.c
Using built-in specs.
Target: i586-linux-uclibc
Configured with:
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=i586-linux-uclibc --enable-languages=c,c++
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--enable-threads --disable-multilib --with-arch=i586 --with-tune=i586
Thread model: posix
gcc version 4.2.1

-quiet -v -I/home/leinhos/src/buildroot/build_i586/staging_dir/usr/include
vc_bridge.c -quiet -dumpbase vc_bridge.c -mtune=i586 -march=i586
-auxbase-strip vc_bridge.o -g -Wall -version -o /tmp/ccbRnIWd.s
ignoring nonexistent directory
ignoring nonexistent directory
ignoring nonexistent directory
ignoring duplicate directory
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:


End of search list.
GNU C version 4.2.1 (i586-linux-uclibc)
        compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9).
GGC heuristics: --param ggc-min-expand=100 --param
Compiler executable checksum: 6e55b40c6d41227a038ca2fc35b4a5f0

-V -Qy -o vc_bridge.o /tmp/ccbRnIWd.s
GNU assembler version 2.18 (i586-linux-uclibc) using BFD version (GNU
Binutils) 2.18
-lpthread -o vc_bridge endian.o cadcac.o pencilbeam.o vcData.o
vcdata_thread.o ds.o remus_parse.o mp_thread.o remus_thread.o
cadcac_thread.o pb_thread.o vc_bridge.o


 khem - 04-06-08 23:30  
Do you see the same problem with both linuxthreads as well as
linuxthreads.old ? 

Issue History 
Date Modified   Username       Field                    Change               
02-20-08 03:29  kannappan      New Issue                                    
02-20-08 03:29  kannappan      Status                   new => assigned     
02-20-08 03:29  kannappan      Assigned To               => uClibc          
02-20-08 04:40  carmelo73      Note Added: 0005174                          
02-20-08 04:40  carmelo73      Status                   assigned => feedback
02-22-08 00:03  kannappan      File Added: a                                
02-22-08 00:06  kannappan      Note Added: 0005224                          
02-22-08 00:13  carmelo73      Note Added: 0005234                          
02-22-08 17:25  vapier         Note Added: 0005254                          
02-28-08 02:32  kannappan      Note Added: 0005494                          
02-28-08 02:34  kannappan      File Added: sample.c                         
03-26-08 14:48  xi             Note Added: 0006074                          
03-26-08 14:54  xi             Note Edited: 0006074                         
03-26-08 14:55  xi             Note Edited: 0006074                         
04-02-08 01:38  bla            Note Added: 0006314                          
04-03-08 09:51  hank_le        Note Added: 0006374                          
04-03-08 10:09  hank_le        Note Edited: 0006374                         
04-06-08 23:30  khem           Note Added: 0006424                          

More information about the uClibc-cvs mailing list