This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> I probably should ask this on the GDB list, but maybe some embedded > gurus on this list can help out as well. I frequently ran into the > situation that GDB backtraces which did not contain a "main()" ran a > astray. I tried very hard to understand GDB's logic regarding > backtraces, the backtrace-past-main option, and all that, but failed > so far. In brief, I found no reliable way to terminate a backtrace > (PPC and i386). The problem is most likely in *your* startup code that calls *your* entry point. Normally, there is a small piece of code in you ASM startup that loads the stack pointer - frame pointer - (depends on the CPU type) with some value (sometimes zero) that tells the stack backtrace code "stop don't go any further" For example on ARM - we load R11, R12, R13, and R14 with ZERO before we call our entry point function. Otherwise - things go a little wacky. Not everybody sees the importance of this when they write own startup code until they have been inside a debugger debugging this sort of stuff. You should probably do the same thing in the top of your interrupt handlers, and places where you do task switches etc. -Duane. ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |