RE: symbolic debug of loadable modules with kgdb light

[Caz Yokoyama <cazyokoyama at gmail dot com>]

Hello Joel,
Here is the patch for 1. Let me know if I forget something. Also any
comments are welcome. Thank you.
-caz

-----Original Message-----
From: Joel Brobecker [mailto:brobecker@adacore.com] 
Sent: Tuesday, September 29, 2009 9:39 AM
To: Caz Yokoyama
Cc: 'Pedro Alves'; gdb-patches@sourceware.org
Subject: Re: symbolic debug of loadable modules with kgdb light

> Do you think we have to check correctness of user input for
> interrupt_sequence?

Yes, if only for the vast majority of users who will be using either
the default or using BREAK.

> Setting-up debugging environment of Linux device driver by gdb is not
> a trivial task

I don't doubt that, and I do not doubt that users prefer flexibility.
The current solution, which offers the user 3 choices for the interrupt
sequence, has no kernel dependency. It's very clear what each choices
does, and I do not understand how allowing free text instead of a defined
set of choices helps make things easier, especially when only specific
choices will actually be accepted in the end. You are arguing that we may
need more choices in the future. I answered that we can worry about that
later, *when/if* the situation actually arises.  Adding more choices is
a matter of seconds with a 10-line patch.

But, again, I also repeat that, if you think this is unnacceptable,
then perhaps we can accomodate extensibility while not needing code
recompilation by using a technical solution based on XML. You can have
a look at how "catch syscall" is implemented for an illustration.
But this can be done as a second phase, after the patch on which
you've been working on is approved and checked in.

In other words:

  1. Implement a patch that adds:
        set/show remote interrupt-sequence <control-c|BREAK|BREAK-g>
        set/show remote interrupt-at-startup [on|off]
     Make the old set/show remotedebug deprecated (please take a look
     at my earlier reply on what I mean by that)

  2. Look into adding extensibility through the use of an XML file

If you prefer to do all the work in one patch, you are welcome to do so,
but you are letting the best be the enemy of good, IMO, and only delaying
the time when vanilla FSF GDB can debug Linux Kernel modules.

-- 
Joel

Attachment: remotebreak.patch
Description: Binary data