From: Daniel Phillips <phillips@phunq.net>
To: Dave Chinner <david@fromorbit.com>
Cc: tux3@tux3.org, sniper <s3c24xx@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Jeff Dike <jdike@addtoit.com>
Subject: Re: [Tux3] Tux3 report: A Golden Copy
Date: Wed, 31 Dec 2008 01:40:49 -0800 [thread overview]
Message-ID: <200812310140.49503.phillips@phunq.net> (raw)
In-Reply-To: <20081231083123.GF10725@disturbed>
On Wednesday 31 December 2008 00:31, Dave Chinner wrote:
> On Wed, Dec 31, 2008 at 12:00:54AM -0800, Daniel Phillips wrote:
> > On Tuesday 30 December 2008 23:34, sniper wrote:
> > > Great, I have mounted tux3 filesystem under UML with stuffs in this mail,
> > > but I still can't debug it with gdb. Anyone gives me suggestion?
> ....
> > In the mean time, you could just tell gdb to mask off all segfaults,
> > but would be kind of problematic for debugging.
>
> Not really. That's the default setting I use for XFS debugging. I
> just put breakpoints on "panic" and "stop" (sometimes
> bust_spinlocks) and just let the kernel panic routine handle the
> segv which will trip a breakpoint. Then just walk back up the stack
> to the function that triggered the real SEGV and go from there.
>
> This is pretty much necessary for XFS debugging because
> just mounting a filesystem causes 8-10 SEGV signals to occur.
> You simply can't run xfsqa when that is occurring...
Thanks for the howto. That was Jeff's suggestion also, but it would
be so much slicker if it was automagic, and first-time users would not
be constantly hitting this. I realize the difficulty. We have two
big tools that are not a perfect match, and don't know how to
cooperate to smooth out the bumps. Sigh. It was ever thus.
UML used to know about gdb, because it had to - the ptrace version of
UML could not be debugged as a regular task so gdb was execced from
UML. The result was very slick. You said "linux debug" and you would
land at the gdb command prompt from which you could continue, or
"linux debug=go" and it would continue without pausing, great for
rapid development. Now, it's all much more high tech and better I am
sure, but not as slick. You have to set up a .gdbinit, it's more to
do and not something you are going to get around to doing on every
machine you might develop on. So I typically end up just typing cont
and lots of carriage returns, not so pretty.
By the way, gdb -args linux ubda=... is very convenient.
Added Jeff to CC. Thanks Jeff, I still think UML is the best kernel
development tool ever.
Regards,
Daniel
next prev parent reply other threads:[~2008-12-31 9:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 3:35 Tux3 report: A Golden Copy Daniel Phillips
2008-12-31 7:34 ` sniper
2008-12-31 8:00 ` [Tux3] " Daniel Phillips
2008-12-31 8:14 ` Justin P. Mattock
2008-12-31 10:09 ` Martin Steigerwald
2008-12-31 17:41 ` Justin P. Mattock
2009-01-02 20:17 ` Martin Steigerwald
2009-01-02 20:36 ` Justin P. Mattock
2009-01-02 22:45 ` Daniel Phillips
2009-01-02 23:11 ` Justin P. Mattock
2009-01-03 1:19 ` Daniel Phillips
2009-01-03 1:32 ` Justin P. Mattock
2009-01-03 3:03 ` Daniel Phillips
2009-01-03 3:39 ` Justin P. Mattock
2009-01-04 3:17 ` Jamie Lokier
2009-01-04 4:15 ` Daniel Phillips
2009-01-04 4:29 ` Justin P. Mattock
2009-01-04 13:04 ` Theodore Tso
2009-01-05 1:10 ` Daniel Phillips
2009-01-05 2:13 ` Jamie Lokier
2009-01-08 2:50 ` Daniel Phillips
2009-01-08 4:38 ` Evgeniy Polyakov
2008-12-31 8:16 ` sniper
2008-12-31 8:31 ` Dave Chinner
2008-12-31 9:40 ` Daniel Phillips [this message]
2008-12-31 14:26 ` Andi Kleen
2008-12-31 18:14 ` sniper
2008-12-31 18:18 ` sniper
2009-01-01 9:56 ` Daniel Phillips
2009-01-01 14:46 ` Daniel Phillips
2009-01-01 23:58 ` Dave Chinner
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=200812310140.49503.phillips@phunq.net \
--to=phillips@phunq.net \
--cc=david@fromorbit.com \
--cc=jdike@addtoit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=s3c24xx@gmail.com \
--cc=tux3@tux3.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