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]

Re: Backtrace of naked functions


> 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]