Re: parse_expression

Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > 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.

Doesn't sound too bad, maybe we should keep it in mind, at last :-)

> > [...]
> > 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?

When I use "thread [%eax]", "thread" is recognized as a registered 
command, and thus, the debugger wouldn't call parse_expression() 
itself. But the thread command would then do when evaluating it's first 
argument, ie.:
	thread_id id = parse_expression(argv[1]);

But if you had put [%eip = 0x12345] at the command line, the debugger 
would have called parse_expression() directly.

> > 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. :-)

But also very useful :-)

> > 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?

It would be loaded when the system is started, and best used as a boot 
module. In fact, debug_init_post_modules() already looks for debugger 
modules on start.
If the module is installed (which should be the default in the standard 
distribution) it'used; if not, all that parse_expression() does is 
strtoul().

Bye,
   Axel.


-------------------------------------------------------------------------
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/