Building glibc

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Building glibc

958 Views
DanJozwiak
Contributor II

Hi:

I'm working with the i.MX27 and trying to establish an environment for debugging application crashes. It turns out that when an abort() call is made (usually via an assert) there is no backtrace in gdb beyond the abort() call. Running the following example with gdb will demonstrate this:

#include <stdlib.h>
void func_a()
{
    abort();

}

int main(int argc, char **argv)
{
   func_a();

}

Having searched the internet it appears that in order to debug with glibc (and get successful backtraces) we need debug information which is stored in something like /lib/debug or /lib/.debug. However, in a typical LTIB build there is no such directory in the rootfs and I believe glibc is not even built during a normal LTIB build but instead a binary package is installed.

 

Looking at the glibc.spec file I noticed that --disable-debug was specified and, assuming that the binaries used in the LTIB rootfs were built with the same, I decided to try to build the glibc package without this option. The glibc package build failed in two separate areas.

 

The first failure occurred when the configure script was run. During the configure you see the following error:

checking version of arm-none-linux-gnueabi-gcc... 4.1.2, bad

followed by:

*** These critical programs are missing or too old: gcc
*** Check the INSTALL file for required versions.

Since the 4.1.2 compiler is what is installed and used by LTIB this didn't make sense. But, in order to continue, I worked around this in the configure script. I then encountered the following error:

arm-none-linux-gnueabi-gcc ../sysdeps/generic/setfpucw.c -c -std=gnu99 -O -Wall -Winline -Wstrict-prototypes -Wwrite-strings     -Wno-uninitialized -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -I../include -I. -I/projects/northend/svn/embedded/celiav1/imx27/stage/ltib/rpm/BUILD/glibc-2.3.2/build-glibc/math -I.. -I../libio  -I/projects/northend/svn/embedded/celiav1/imx27/stage/ltib/rpm/BUILD/glibc-2.3.2/build-glibc -I../sysdeps/arm/elf -I../linuxthreads/sysdeps/unix/sysv/linux/arm -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/arm -I../sysdeps/unix/sysv/linux/arm -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/arm/fpu -I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/include -isystem /projects/northend/svn/embedded/celiav1/imx27/stage/ltib/tmp/glibc//opt/freescale/rootfs/arm//usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h       -o /projects/northend/svn/embedded/celiav1/imx27/stage/ltib/rpm/BUILD/glibc-2.3.2/build-glibc/math/setfpucw.o
/export/home/Test/tmp/ccBOWWbh.s: Assembler messages:
/export/home/Test/tmp/ccBOWWbh.s:12: Error: selected processor does not support `rfs r3'
/export/home/Test/tmp/ccBOWWbh.s:19: Error: selected processor does not support `wfs r2'

 

I have not found a way around this error yet. From the build command-line the processor architecture has not been specified. But specifying it using options like -mcpu=arm9 or -march=armv5te have not helped. So (finally) a couple of questions:

1. is it reasonable to think that the glibc package should build under LTIB or is it more complex and the glibc package is included for reference?

2. if glibc is not buildable how can we debug effectively with GDB without debug information from glibc?

3. if glibc should be buildable, is there information available on how to do this?

 

Thanks for your help,

Dan

Labels (1)
Tags (2)
0 Kudos
0 Replies