From: George Anzinger <george@mvista.com>
To: Andi Kleen <ak@muc.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH]Call frame debug info for 2.6 kernel
Date: Tue, 23 Mar 2004 13:45:41 -0800 [thread overview]
Message-ID: <4060B005.4020804@mvista.com> (raw)
In-Reply-To: <m3n0685nfp.fsf@averell.firstfloor.org>
Andi Kleen wrote:
> George Anzinger <george@mvista.com> 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@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2004-03-23 21:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1AR5s-75I-27@gated-at.bofh.it>
[not found] ` <1CHY0-1Uw-9@gated-at.bofh.it>
2004-03-23 2:04 ` [PATCH]Call frame debug info for 2.6 kernel Andi Kleen
2004-03-23 21:45 ` George Anzinger [this message]
2004-03-24 6:25 ` Andi Kleen
2004-03-24 16:20 ` George Anzinger
2004-03-17 21:37 Fixes for .cfi directives for x86_64 kgdb Jim Houston
2004-03-23 0:17 ` [PATCH]Call frame debug info for 2.6 kernel George Anzinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4060B005.4020804@mvista.com \
--to=george@mvista.com \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox