This is a second try at this with a different subject and the note on gdb 
version at the end.

Here is the dwarf2 patch.  It assumes that mm-kgdb is already there, but there
are really very few dependencies.  With little effort it should work with Amit's
version.

What it does:

This patch allows back trace and "up" commands to go smoothly back to the root
of the stack through interrupt frames, trap frames, you name it.  It also tells
the asm compile engine to save the temp source as this is what gas builds debug
records for.  (This is not needed to get the back trace, its just "nice".)

I removed the debug info overlap in kconfig.  Kgdb sets -gdwarf2 while that set
-g.  Not nice to have both.

There is only one code change and that is to push a "1" on the stack so that it
looks like the return address for idle tasks other than the cpu 0 idle task.
This is done so that a "bt" on that task will not go on forever (I had a screen
with 1000+ levels on it...).

What it is:

The dwarf2.h file from the binutils tree is here as it is there.  There is an
awk script to build dwarf2-defs.h which is nothing but all the constants, from
that file, in a form that asm AND c understand.  The script works for this file,
for other files you are on your own.  This translation is forced in the main
make file, I suppose this could be done more cleanly, but... I just did not want
to figure out the make maze.

The dwarf2-lang.h file is a set of macros that make writing dwarf2 half way
enjoyable and much more understandable.

All most all of the dwaft2 code is at the end of entry.S but for 2 lines in head.S.

Daniel keeps telling me that this should be done in asm, and I suppose one could
do it there, but it does not support the expression code as yet and that is
where most of the magic is.

Oh and by the way, you do need call frames (CONFIG option) as without them gdb
will most likely get lost in the switch code in schedule().  This comes up in
the "info thread' command so it is not uncommon.

What it needs:

For the dwaft2 expression code to be correctly understood by gdb you will need 
to get the CVS version of gdb as of at least 1/24/04.  Otherwise, the bug in the 
gdb expression code will most likely stop the unwind at the intrerrupt/trap 
frame regardless of having interrupted the kernel and not user space code.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml