[Buildroot] Core Files on ARM

[Buildroot] Core Files on ARM

[cmc2001]

TWIMC,
Forgive the noob question, but we have a busybox'd target which we've
configured to produce partial core files when our app crashes.  However, it
seems to only have spotty backtrace information - specifically, only a stack
trace for one thread.

Busybox 1.13.4
g++ 4.2.1
kernel 2.6.28.2

I know I'm not alone after trawling google, but I'm yet to find anything
approaching a definitive answer.

I've been banging my head on this problem for several days now and the more
I dig, the more possible problems I discover (the latest being the g++ ARM
toolchain and its limitations).  Would this corefile problem be resolved if
I moved up to:

Busybox 1.15.3
gcc 4.4.3
kernel 2.6.29.4

Also, if Busybox's menus is dumbing down my control of corefiles a little
too much, is there an agreed way of subverting it that won't get me into
trouble down the track?

cya
Craig
-- 
View this message in context: http://old.nabble.com/Core-Files-on-ARM-tp27900409p27900409.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Core Files on ARM

[cmc2001]

cmc2001 wrote:
> 
> Forgive the noob question, but we have a busybox'd target which we've
> configured to produce partial core files when our app crashes.
OK, it was obviously a bigger noob question than I realised.  I realise now
that buildroot sits at the top of the tree, not BusyBox.

Would I be right in saying that the BR2_PTHREAD_DEBUG flag is for debugging
the pthread library, not so much producing better thread info in application
core files?

I didn't run across an obvious setting for enabling complete core files in
Config.in.  Where exactly would such a beast live?  Is there a separate
Config.in for kernel-specific stuff?

cya
Craig
-- 
View this message in context: http://old.nabble.com/Core-Files-on-ARM-tp27900409p27900834.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.