public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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