This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Processing of convenience variables for scripts ...
On Thu, Nov 21, 2002 at 04:22:53AM +1030, Richard Sharpe wrote:
> On Wed, 20 Nov 2002, Daniel Jacobowitz wrote:
>
> > On Wed, Nov 20, 2002 at 11:32:24AM -0500, Andrew Cagney wrote:
> > > >The loop works, but add-symbol-file seems to be called without the
> > > >>convenience variables being expanded.
> > > >>
> > > >>Have it got that right?
> > > >>
> > > >>If so, what would be the first step to get them expanded?
> > > >
> > > >
> > > >add-symbol-file takes constants, not expressions - so variables are not
> > > >expanded. This should probably change but it's not clear how, given
> > > >the parser...
> > >
> > > A quick/dirty hack would be:
> > >
> > > eval .....
> > >
> > > similar to the SH equivalent. I suspect an eval will be needed anyway.
> >
> > Honestly, I'd rather define the CLI grammar I've been talking about
> > than add any more quick hacks. That's a good 6.0 thing to do, clean up
> > our CLI a little...
>
> I have a short-term need and a long-term need.
>
> I am willing to expend effort on both. Where is the description of this
> grammar?
In that case, in the short term, it would be worthwhile to implement
eval. A simple version would just find any individual word that
started with a $ and substitute variables, and end up with something
like "eval add-symbol-file $name $addr".
The long-term grammar is still entirely in my imagination, alas. It
requires:
- Examining and recording the syntax of all our existing CLI commands
(ouch!). The manual is good but not complete enough IMVHO; people
add quirks to functions without documenting them.
- Determining which syntax structures we need to preserve and which
should go.
- Parsing CLI lines before calling the assigned functions, according
to some data registered with the handler function. This will
involve changing syntax for at least some commands, I expect. I
think it's worthwhile but we need to see how invasive it would be.
This can be done a bit at a time.
I want to get decode_line_1 tamed a bit first... David has made
astonishing progress cleaning it up, next will be to characterize its
behavior a little better.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer