Re: [PATCH v2] Fix gdb crash when trying to print the address of a synthetic pointer.

[Martin Galvan <martin dot galvan at tallertechnologies dot com>]

On Wed, Jun 24, 2015 at 8:13 AM, Pedro Alves <palves@redhat.com> wrote:
> On 06/20/2015 04:25 AM, Martin Galvan wrote:
>> Yes, 'function' ends up inlined. If we try to set a breakpoint at a
>> line inside 'function', the breakpoint will be set at an address we'll
>> never hit, thus we need to advance using 'step' and 'next' instead.
>
> Then it sounds like you were putting a breakpoint at a line that was
> optimized out.  If you put the breakpoint at the same line that you
> "step" and "next" to, then it should work, I think.  You'll still
> need a "step" to go from real stack frame to inline frame, as GDB always
> presents you the stack frame on breakpoint hits.

That's what I tried at the beginning. However, if I set the breakpoint
at the line I step to, using "continue" will either take me to an
address after the one I want to stop at, or just finish the program.

> Hmm, that looks too long to me and still escaping out a detail
> that isn't really that interesting to the user.  I was just thinking:
>
> if (is reference)
>  "Attempt to take address of a synthetic reference."
> else
>  "Attempt to take address of a synthetic pointer."

The case on which the variable is an actual synthetic pointer (as
opposed to a synthetic reference) doesn't seem to reach value_addr;
instead it prints the "Can't take address of foo which isn't an
lvalue" message from address_of_variable.

If you think it's ok, I'll print "Attempt to take address of a
synthetic reference" at value_addr, and move the check inside the
TYPE_CODE_REF path.

>> I haven't been able to test this so far because the test requires an
>> x86-like target, which I don't have at hand. I'll keep you posted,
>> though.
>
> Do you have an x86-64 box?  If so, you can just run the test with:
>
>  make check RUNTESTFLAGS="--target_board=unix/-m32 gdb.dwarf2/implptr.exp"

That worked alright. Is this documented somewhere?

>> Assuming gdb crashes there too, couldn't I just add a "print &j" test
>> there and discard the synthetic-pointer-reference.exp test altogether?
>
> Actually from your description, I assume it _doesn't_ crash, because it's
> not a reference.  But it's not tested presently, so who know.  I think it's
> worth it to have both pointers and references covered.

You're right, it doesn't crash. I'll still add a test to implptr.exp
to catch the "Can't take address of foo which isn't an lvalue"
message, though.

About not using printf inside synthetic-pointer-reference.cc, is there
any way to make sure gcc won't optimize 'arg' out completely other
than that? Declaring it as volatile doesn't seem to work.