RE: symbolic debug of loadable modules with kgdb light

[Caz Yokoyama <cazyokoyama at gmail dot 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