Re: Type information in -data-evaluate-expression

[Nick Roberts <nickrob at snap dot net dot nz>]

 > Ok, I get this now.
 > 
 > But that's nice. I am running with "set unwindonsignal on" anyway as my 
 > "custom data dumpers" tend to produce (expectedly so...) segmentation 
 > faults when being thrown on uninitialized data structures.
 > 
 > So this really does not hurt. I can even call  -data-evaluate-expression
 > abort() directly and am still able to continue debugging.

I guess other unpleasant things could happen, like variables changing value.

 >...
 > Uh... I see a possible way to improve things, but this would be certainly 
 > _way_ more intrusive than the proposed two-line addition we are currently 
 > discussing so extensively ;-)

I'm discussing other, possibly better, alternatives.  I guess there's no harm
in your change as long as you provide a test for the testsuite, documentation,
maintenance etc... but a global maintainer approves the change anyway.

 > The idea is to run custom code in certain cases, e.g. when outputting 
 > "type=foo,value=..." fields one would be able to hook in code which gets
 > passed type information and start address and some kind of stream to
 > write to and then _I_ could have my code to output e.g.
 > 
 >   value=[{name="length",type="size_t",value="2005",readonly="true"},
 >         {name="0",type="std::string",value="first item"},
 >        ...  {name="2004",type="std::string",value="two thousand and fifth item}]
 > 
 > Unfortunately gdb scripts are ... erm... 'a bit' too slow to provide that
 > functionality for structures containing more than a handful items, but 
 > the idea also works with compiled code injected into the debugged process. 
 > I am doing that currently using dlopen/LoadLibraryA and it "works" (even with 
 > unitialized objects -- it would btw be really nice if _that_ information were
 > available without going through segfaults...)

Such a change is way over my head, but GDB runs on many architectures and I
think it would need to be portable.

 >...
 > > If execution is at the arrow, the user might place the mouse over the first
 > > occurrence of i and expect the value 1 to be displayed.  However, since
 > > -data-evaluate-expression evaluates relative to the current line, 10 would
 > > actually be displayed.
 > 
 > Right. Living a programmer's life is risky. Computers are lying to you all
 > the time...  [The problem is that s/Computers/Humans/ and
 > s/programmer's/real/ does not change the truth value at all ;-}]
 > 
 > [Apart from that: My target group prefers getting tooltips that are
 > sometimes (or even most of the time) wrong over getting no tooltips at all.]

Life _is_ risky but, if possible, I still like to improve the odds.

-- 
Nick                                           http://www.inet.net.nz/~nickrob