From: Caz Yokoyama <cazyokoyama@gmail.com>
To: "'Joel Brobecker'" <brobecker@adacore.com>
Cc: "'Pedro Alves'" <pedro@codesourcery.com>, <gdb-patches@sourceware.org>
Subject: RE: symbolic debug of loadable modules with kgdb light
Date: Tue, 29 Sep 2009 16:12:00 -0000 [thread overview]
Message-ID: <7063C3E99BE344B2B98EDC0318ED852A@xpjpn> (raw)
In-Reply-To: <20090929051929.GL9003@adacore.com>
Hello Joel,
Do you think we have to check correctness of user input for
interrupt_sequence? Setting-up debugging environment of Linux device driver
by gdb is not a trivial task for the first timer. Connect serial port,
validate its connection, modify menu.lst, reboot, re-compile device driver
with -g -O0. It took 2 weeks in my case. I recently consults 2 people who
set-up Linux device driver debugging environment who failed. The people who
debug device driver are not tape monkeys. They prefer flexibility. At the
same time, almost only people who touch interrupt_sequence are kernel
developers. Therefore, I prefer send_interrupt_sequence () which does not
have kernel dependency and has flexibility of user setting.
-caz
-----Original Message-----
From: Joel Brobecker [mailto:brobecker@adacore.com]
Sent: Monday, September 28, 2009 10:19 PM
To: Caz Yokoyama
Cc: 'Pedro Alves'; gdb-patches@sourceware.org
Subject: Re: symbolic debug of loadable modules with kgdb light
> I know Magic SysRq is the one for Linux kernel. I planned to propose BREAK
> for Xen hypervisor if my patch were approved. I don't know what
> interrupt_sequence is on other OSes. However, I believe that introducing
the
> possible variations into gdb is not your intention. You don't want to
change
> the code when OS changes its interrupt_sequence or supporting new OS.
In my opinion, if you have a debugger that works with BREAK, this
will help supporting your suggestion to use BREAK. If you want
extensibility while at the same time being able to check the value
entered by the user, then perhaps the solution is with the use of
an XML file, similar to what has been done for the "catch syscall"
command. I am not very familiar with this part of the debugger,
but other maintainers are. However, I think you're worriying about
something that may or may not become an issue. I'm not saying it is
a bad thing, but you have something that's very close to acceptable
and will work for your current situation (current Linux kernel). Was
it Lean Programming that said fix a weakness only when it becomes
an issue? With the current proposed user interface, I believe we should
be able to expand the implementation to accomodate other various
sequences.
> >Please let us also know if you'd prefer someone else to review your
> patches.
> I am new to gdb mailing list. I know nobody who is a maintainer of gdb.
What I meant to imply is that, if you think there is a problem with
my reviews, I can ask someone else from the group of maintainers to
take over this thread.
--
Joel
next prev parent reply other threads:[~2009-09-29 16:12 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-09 15:51 Caz Yokoyama
2009-04-24 15:33 ` Tom Tromey
2009-04-24 16:49 ` Caz Yokoyama
2009-04-26 0:39 ` Caz Yokoyama
2009-05-15 21:14 ` Caz Yokoyama
2009-05-15 21:23 ` Pedro Alves
2009-05-15 21:34 ` Daniel Jacobowitz
2009-05-15 21:41 ` Caz Yokoyama
2009-05-15 22:13 ` Michael Snyder
2009-05-15 22:25 ` Caz Yokoyama
2009-08-07 7:17 ` Caz Yokoyama
2009-08-07 9:22 ` Eli Zaretskii
2009-08-07 20:42 ` Caz Yokoyama
2009-09-23 0:48 ` Joel Brobecker
2009-09-23 1:39 ` Daniel Jacobowitz
2009-09-23 4:16 ` Caz Yokoyama
2009-09-23 11:36 ` Caz Yokoyama
2009-09-24 16:40 ` Caz Yokoyama
2009-09-24 22:42 ` Caz Yokoyama
2009-09-25 16:06 ` Joel Brobecker
2009-09-26 3:43 ` Caz Yokoyama
[not found] ` <535d47e30909260627n662135a1hf6d1a0bb33368b3a@mail.gmail.com>
2009-09-29 1:58 ` Joel Brobecker
2009-09-29 3:23 ` Caz Yokoyama
2009-09-29 4:22 ` Joel Brobecker
2009-09-29 4:58 ` Caz Yokoyama
2009-09-29 5:19 ` Joel Brobecker
2009-09-29 16:12 ` Caz Yokoyama [this message]
2009-09-29 16:39 ` Joel Brobecker
2009-09-30 4:45 ` Caz Yokoyama
2009-09-30 17:28 ` Joel Brobecker
2009-09-30 19:16 ` Eli Zaretskii
2009-09-30 20:12 ` Joel Brobecker
2009-10-01 3:48 ` Caz Yokoyama
2009-10-01 4:08 ` Eli Zaretskii
2009-10-01 4:51 ` Caz Yokoyama
2009-10-01 20:04 ` Eli Zaretskii
2009-10-01 16:33 ` Joel Brobecker
2009-10-01 17:18 ` Caz Yokoyama
2009-10-01 19:37 ` Joel Brobecker
2009-10-01 19:53 ` Caz Yokoyama
2009-10-01 20:25 ` Eli Zaretskii
2009-10-01 20:19 ` Eli Zaretskii
2009-10-01 20:29 ` Caz Yokoyama
2009-10-01 20:46 ` Joel Brobecker
2009-10-01 21:10 ` Daniel Jacobowitz
2009-10-01 21:58 ` Caz Yokoyama
2009-10-01 22:13 ` Pedro Alves
2009-10-01 23:04 ` Caz Yokoyama
2009-10-01 23:32 ` Joel Brobecker
2009-10-02 1:18 ` Caz Yokoyama
2009-10-02 22:14 ` Joel Brobecker
2009-10-02 8:55 ` Eli Zaretskii
2009-10-28 15:05 ` Joel Brobecker
2009-10-01 20:13 ` Caz Yokoyama
2009-05-15 21:34 ` Caz Yokoyama
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=7063C3E99BE344B2B98EDC0318ED852A@xpjpn \
--to=cazyokoyama@gmail.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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