Re: [PATCH]Call frame debug info for 2.6 kernel

[George Anzinger]

Andi Kleen wrote:
> George Anzinger <george@xxxxxxxxxx> writes:
>
>
> > This patch adds call frame debug record generation for entry.S frames.
>
>
> [...]
>
> Sorry, but that's quite ugly and will be hard to maintain (kinda like
> maintaining an own assembler on your own) I think it would be far
> better to require recent binutils for DEBUG_INFO builds and use the
> .cfi_* mnemonics. They make dwarf2 code *much* simpler and cleaner.
>
> Overall I think it's a good idea to add full dwarf2 annotation to
> the i386 kernel, but not without assembler please.

Hi Andi,

I just knew you would say that :).

I think I have said before that the current .cfi support in the assembler is not 
up to the job.  In fact gdb 6.0 also has a nasty bug that this code works 
around.  The main issue is the ability to use the dwarf2 cfi expression to build 
a call frame that determines if the interrupt/ trap frame returns to user space 
or to the kernel.  I think (I confess I have not tried) this may be doable with 
the .cfi escape op code, but I suspect the result would be just as ugly as this 
patch is.  You would have to roll your own .uleb128 and .sleb128 numbers, for 
example.   Also, you would need to be able to define labels in the dwarf code 
(or intuit how var the assembler is going to put your target and use that offset).

The long and short of it is, to do it at all, you need to have a fair knowledge 
of dwarf2.  Once you get to that, I suspect one way is as good as another.

At this point, the code works with kgdb, which, itself is not in the kernel.  I 
welcome any one who wants to help do it correctly.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/