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

[Pedro Alves <palves at redhat dot com>]

On 06/28/2015 06:05 AM, Martin Galvan wrote:
> 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.

Sounds OK.

> 
>>> 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?

Not sure.  I'd assume the dejagnu manual would say something about it,
but I if it's there, I can't find it right now.

Yao wrote a blog post about this a while ago:

 https://yaoqi.wordpress.com/2014/09/01/powerful-testing-with-dejagnu/

Guess it would be good to add something to:

 https://sourceware.org/gdb/wiki/TestingGDB


> 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.

Odd.

But looking again, I see that all of implptr-optimized-out.exp,
implptrpiece.exp and implptrconst.exp already use the Dwarf::assemble
machinery to exercise  GNU_implicit_pointer related things.
It's probably not that hard to base a reference test case on one
of those.  I'd probably pick implptr-optimized-out.exp.
Could you give that a try?

The main advantage of the Dwarf::assemble machinery is that
then the test is both target and compiler independent.

Thanks,
Pedro Alves