Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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



      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