Re: parse_expression

On 2007-05-26 at 19:29:24 [+0200], Axel Dörfler <[email protected]> 
wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > > [...]
> > > 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.

So what you're saying is, if the input line starts with "[" the debugger 
evaluates the whole line as an expression, otherwise it must start with a 
command name and the command parses it's arguments as needed, right?

BTW, I think, the "[...]" blocks have to be scanned by the debugger at any 
rate, so that e.g. "db [lastAddress + 10] 20" passes just two arguments to 
the db command ("[lastAddress + 10]" and "20").

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

I suppose it would be powered by architecture specific functions like:

	bool arch_set_iframe_register(struct thread* thread, int iframeNumber,
		const char* registerName, int64 value);
	bool arch_get_iframe_register(struct thread* thread, int iframeNumber,
		const char* registerName, int64* value);

The bool result may as well be a status_t, though the only error I can 
imagine at the moment is that the register name is invalid, respectively 
the register not included in the iframe.

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

OK, I see.

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/