It's good to know that you already have a full C grammar/compiler using
CTF data. Having a built-in C-like language in mdb/kmdb will be great and
is definitively the goal to reach (I also had this idea but interfacing mdb
with Perl was much easier and quicker).
I think we can make that goal and the reflexion you are proposing part
of the project, this will help keep track of suggestions and we can study
what benefits are provided by languages mdb will be interfaced with. This
will also help define what would be useful for such a built-in language.
So the project can be twofold:
- provide information how scripting languages can be interfaced with
mdb and provide support for some languages.
- study and possibly implement a built-in language into mdb.
I propose to change the project description to:
The purpose of this project is to add support for scripting languages
to the modular debugger (MDB). Support will be added as an interface
to some existing scripting languages and ultimately as a built-in
language into MDB.
Scripting languages will use the MDB API so that MDB commands and functions
can be invoked from the scripting language. They will also use CTF type
information so that data structure can be directly accessed from the
scripting language.
This project will allow to write new MDB commands using scripting languages
instead of having to write and compile a C module. Thus this will greatly
reduce the time to write new MDB commands.
This project will initially interface the PERL language with MDB.
alex.
Mike Shapiro wrote:
> On Fri, Feb 22, 2008 at 12:55:04PM -0800, Alexandre Chartre wrote:
>>> I see some merits here, but one possible area of consideration is that
>>> mdb benefits from being basically syntax compatible with kmdb. The
>>> same dcmds that work in mdb generally are also available in kmdb. I'd
>>> hate to see mdb extended in ways which don't easily allow for the same
>>> extensions to be done in kmdb.
>> I totally agree with you, it is very upsetting to be used to some mdb
>> cmds and to discover it doesn't exist with kmdb. But in most cases you can
>> collect a crash dump and analysis it with mdb.
>>
>>> Of course, for stuff not related to kernel debugging, I probably care a
>>> lot less. Although, to be quite honest, mdb seems a lot less useful for
>>> debugging userland programs, if only because tools like dbx and gdb seem
>>> so much better suited to that particular task.
>> That's also very useful for debugging kernel on live system or for crash
>> dump analysis. A big advantage is that you can change your commands very
>> quickly (for example if you change a structure while developing and you
>> want a quick command to see your change).
>>
>> alex.
>
> When I originally designed MDB, it predated my work on CTF, and thus the
> native type system of the kernel was not available for use in the debugger.
>
> I recall writing in my notebook at the time that ideally you want to be
> able to support the natural expressions of the language you're debugging,
> which for MDB is almost always C, with a mix of assembly and maybe C++.
> But mentally you are thinking in the C model since you're fundamentally
> doing systems-level debugging on a UNIX operating system.
>
>>From this perspective, I always intended to revisit the language issue
> once we had the type information in place, but I've yet to find the time.
> One thing I can say is that I've always found it a bit cumbersome to
> try to retrofit the syntax and semantics of one language into another.
>
> So while I'm a strong supporter for bridges to as many languages as people
> find useful for writing scripts such as the Perl example, I've always thought
> MDB would benefit from simply native C expression support with a very
> minor set of extensions to call dcmds and do a few of the existing things.
>
> One idea I've wanted to play with is leveraging some of the DTrace work,
> in that I did go off and write a full C grammar/compiler using CTF data,
> so that already exists and could be leveraged. Also I do want something
> that works the same way in kmdb and mdb.
>
> My suggestion to the community is to start out by making a list of questions/
> examples of things you want to achieve in the debugger and modeling and
> comparing those using a variety of different syntaxes.
>
> -Mike
>
