Core Files on ARM
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
Signature · 2 lines
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.
Quoted 3 lines · 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
Signature · 2 lines
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.