Re: parse_expression

On 2007-05-26 at 12:27:57 [+0200], Axel Dörfler <[email protected]> 
wrote:
> "Morgan Howe" <[email protected]> wrote:
> > I'm thinking about implementing the parse_expression call for the
> > KDL,
> > and so Ingo thought I should run it past everyone in the list to see
> > what capabilities they would like from this function.  First, here
> > are
> > Ingo's requests:
> > > Personally I'd even consider a basic procedural language --
> > > including if and
> > > loop constructs as well as command invocation from within
> > > expressions.
> 
> I think that's a bit too much - at least I can't see to make use of
> such a powerful language in KDL. But maybe Ingo can deliver some
> striking examples for it :-)

When I was debugging some VM/cache bugs a while ago, it occurred to me, 
that this would be a very handy feature. To look through a few thousand 
pages for something specific manually is not really an option. It doesn't 
matter that much, if the bug is easily reproducible -- then one can simply 
add more debug output or temporarily add a specific debugger command -- but 
otherwise having powerful default tools for analyzing the problem would be 
nice. Anyway, I agree that this might be a bit much.

> [...]
> > > Since 64 bit architectures are already around, variables should be
> > > 64 bit
> > > wide. An initial assignment should declare a variable, and there
> > > should be
> > > some way to explicitely undeclare it again. I believe, it would be
> > > great, if
> > > a debugger command could set temporary variables (in a special name
> > > space,
> > > e.g. starting with "_") that are declared until the next command is
> > > invoked.
> > > E.g. the "sc" command could set "_ebp", "_eip", etc., so that after
> > > a "sc
> > > 0x17" one could type "db [_ebp] 32" or save interesting values in
> > > permanent
> > > variables ("[lastFrame = _ebp]", "[crashAddr = _eip]").
> 
> The general ideas sound nice, even though they would indeed render the
> call a bit superfluous if it would be automatically applied.
> But since it returns numbers anyway, it should still be applied on
> single arguments as needed by the debugger functions (ie. the
> expression parser would also run when the command is not known).

I don't quite get what you mean. When should it be applied to which 
arguments? Examples?

> Beyond the temporary variables mentioned by Ingo, I would like to see
> some hardware registers exposed as variables directly (could also be in
> a special namespace, like %eip) - this should not only allow using
> their values, but also to set them to a specific value.

Ooh, nasty. :-)

> Given the complexity, I would realize this expression parser as a
> module - the default built-in version would simply do a strtoul(string,
> NULL, 0) on everything it gets, while the module version could be much
> more powerful. If it eases development, moving the code into a module
> could also be done as the last step, if you prefer.

Now I'm confused. How would it help, if additional debugger functionality 
was in a module? We can't load the module from KDL. Or who is supposed to 
load it and when?

CU, Ingo

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/