This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Type information in -data-evaluate-expression
> 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