This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI] -stack-list-variables
> That's only the "origin" of the values. Inside the function, parameters and locals
> obey exactly the same rules.
If you are trying to understand how a variable gets a value then you're interested
in the origin of that value.
> > If the front end doesn't care, it can always group these together.
>
> I was saying that all frontends I know do not seem to care, therefore it
> does not seem like we should care.
I don't really know what other frontends do but it appears useful to me.
> > > Even
> > > if we decide this information is necessary, would it not be better to present it
> > > like this:
> > >
> > > ^done,variables=[{name="i", arg="1"},{name="asdf"}]
> > >
> > > as this format is more extensible in case some other frontend might need
> > > even more finer details?
> >
> > I don't see how this helps. Breaking locals and args down further would require
> > a new command for backward compatibilty reasons.
>
> Why? You can always add new field, e.g.
>
> ^done,variables=[{name="i", truly-magic-kind-of-symbol="1"},{name="asdf"}]
Perhaps I misunderstood. I thought you mean't a third kind of local, whatever that might
be, but we could equally add a new field like this too:
^done,variables={args=[{name="i", truly-magic-kind-of-symbol="1"},{name="j"}],
locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}
--
Nick http://www.inet.net.nz/~nickrob