This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]