From: "Amit S. Kale" <amitkale@linsyssoft.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: kgdb support for gdb
Date: Mon, 25 Oct 2004 05:50:00 -0000 [thread overview]
Message-ID: <200410251118.16866.amitkale@linsyssoft.com> (raw)
In-Reply-To: <20041004172333.GA15074@nevyn.them.org>
On Monday 04 Oct 2004 10:53 pm, Daniel Jacobowitz wrote:
> On Mon, Oct 04, 2004 at 10:05:24PM +0530, Amit S. Kale wrote:
> > I don't suppress any frames. I insert a fake frame so that the fake frame
> > can do the job of reporting correct registers to the previous frame. IT
> > works more or less like inline functions. At present inline functions
> > don't insert fake frames, but I believe it's being worked on.
>
> FYI, I have inline frames mostly working. They are sort of "fake"
> frames... but I haven't taken a look at your code, so I'm not sure
> whether what you did is comparable.
>
> > Let me state the problem I am trying to solve. You may be able to provide
> > a better solution to that.
> >
> > schedule() function has a call to macro switch_to. The switch_to macro is
> > an architecture specific macro. It has hand written assembly code that
> > does a part of the context switching job. This code manipulates eip and
> > esp in a non-standard way. Present gdb can't produce backtraces correctly
> > if the frame 0 is inside switch_to. That's obvious since gdb doesn't have
> > dwarf information for those instructions.
> >
> > A few things have been tried to help gdb with this problem. This one is
> > worth mentioning: We report the esp as it would be when switch_to is
> > complete. Since gdb doesn't look into switch_to code, it starts
> > interpretations where switch_to ends. So this works ok for most part. It
> > doesn't solve the problem of all registers, though. The switch_to code
> > has been written intelligently (read over-engineered) to save only those
> > registers which would be expected by gcc to be correct when schedule()
> > function returns. So this task becomes unmanageable and error-prone.
>
> Can you explain why this can't be done with additional DWARF annotation?
Adding dwarf annotation is one problem. It an assembly code so adding dwarf
annotation isn't easy. George Anzinger has done that in other places (do_IRQ
in particular), but it's in binary. Not all assemblers used by people support
the .cfi directives. Highly unmaintainable stuff. It's better not to have
that than gdb reporting incorrect information.
switch_to is anyway a context switch code. gdb certainly can't be made to
understand it. It's very similar to signal trampolines where gdb can't debug
the part that resides outside the trampoline code (kernel code). One side
effect of inserting this fake frame is that users can't single step in that
frame. It's good because they accidentally don't try to debug context
switches through gdb.
-Amit
prev parent reply other threads:[~2004-10-25 5:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 7:45 Amit S. Kale
2004-10-01 9:13 ` Andreas Schwab
2004-10-01 9:57 ` Amit S. Kale
2004-10-01 22:01 ` Mark Kettenis
2004-10-02 3:52 ` Amit S. Kale
2004-10-02 22:48 ` Mark Kettenis
2004-10-04 14:56 ` Andrew Cagney
2004-10-19 12:45 ` Amit S. Kale
2004-10-04 15:14 ` Andrew Cagney
2004-10-04 15:42 ` Amit S. Kale
2004-10-19 12:55 ` Amit S. Kale
2004-10-04 15:55 ` Andrew Cagney
2004-10-04 16:36 ` Amit S. Kale
2004-10-04 17:23 ` Daniel Jacobowitz
2004-10-25 5:50 ` Amit S. Kale [this message]
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=200410251118.16866.amitkale@linsyssoft.com \
--to=amitkale@linsyssoft.com \
--cc=cagney@gnu.org \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
/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