gdb cannot recognize symbol format elf32-i386

[Sergio M. Ammirata, Ph.D.]

Hello Mike,

On 11/6/09 6:00 PM, "Mike Frysinger" <vapier at gentoo.org> wrote:

> On Friday 06 November 2009 17:22:12 Sergio M. Ammirata, Ph.D. wrote:
>> Thanks for your advise. I was indeed compiling gdb as part of the buildroot
>> process. I compiled it on my target instead and now I can see the backtrace
>> without any errors (I use a plain ./configure and make on the original gdb
>> source).
> 
> file a bug with the buildroot people then
> 

I will do that. And will also report the coreutils not compiling problem. I
did not realize they had a different list.

>> Program terminated with signal 11, Segmentation fault.
>> [New process 8262]
>> [New process 8260]
>> [New process 8249]
>> [New process 8350]
>> [New process 8248]
>> [New process 8194]
>> [New process 8246]
>> [New process 8247]
>> [New process 8259]
>> [New process 8251]
>> #0  0x3767fb0e in malloc () from /lib/libc.so.0
>> (gdb) bt
>> #0  0x3767fb0e in malloc () from /lib/libc.so.0
>> #1  0x00000000 in ?? ()
>> 
>> How can I dig deeper into this error now?
>> Should I compile the uclibc with full debug symbols and remove the strip
>> option in the config as well?
> 
> and enable debugging in your code
> 

I already had debugging enabled in my code. The app doubled in size with the
symbols. I will enable the other debugging parameters and try again.

>> This crash was not happening with 0.9.28 with the same application.
> 
> that doesnt completely implicate uClibc as the problem.  often times changing
> C library can make the application behave slightly differently and thus crash
> in ways it didnt before.
> -mike

I am compiling in the exact same machine with almost identical uclibc-config
as in 0.9.28. The only significant difference is the version of the gcc
library (gcc 4.3.4 vs. 3.x) being compiled by the toolchain. Is this what
you mean?

I have also tried with different gcc selection (4.3.3 and 4.4x) with the
same results.

Thanks,

Sergio