This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Fix gdb crash when trying to print the address of a synthetic pointer.
- From: Pedro Alves <palves at redhat dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 30 Jun 2015 11:45:57 +0100
- Subject: Re: [PATCH v2] Fix gdb crash when trying to print the address of a synthetic pointer.
- Authentication-results: sourceware.org; auth=none
- References: <1434257323-18553-1-git-send-email-martin dot galvan at tallertechnologies dot com> <557EB455 dot 5040909 at redhat dot com> <CAOKbPbZb8jGvN0ri65Oc2iFDrFrveKgC-CAW78dc1G+ZxiXPPQ at mail dot gmail dot com> <558A90D7 dot 30505 at redhat dot com> <CAOKbPbbg-VV77=3KKYu=fYZPQonSWNesRyJjq_34rXq9R7SyqQ at mail dot gmail 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