Re: Merge C++ conversion into trunk (0/6 - Overview)

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Richard Guenther]

On Sun, 12 Aug 2012, Diego Novillo wrote:

> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch.  As described in 
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that stage 1 always
> builds with a C++ compiler.
> 
> Other than the bootstrap change, the patches make no functional
> changes to the compiler.  Everything should build as it does now
> in trunk.

...

and debugging becomes a nightmare (hello gdb people!)

(gdb) call debug_tree (*expr_p)
 <integer_cst 0x7ffff695d7c0 type <integer_type 0x7ffff67fa5e8 int> 
constant 9>
(gdb) call debug_tree (0x7ffff67fa5e8)
Cannot resolve function debug_tree to any overloaded instance

filing bugs does not help (as usual).  
http://sourceware.org/bugzilla/show_bug.cgi?id=13356

It's a year old, to prep for this change.  Now we're here.  Debugging
sucks.

Great.
Richard.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-15 07:59 , Richard Guenther wrote:

> (gdb) call debug_tree (*expr_p)
>   <integer_cst 0x7ffff695d7c0 type <integer_type 0x7ffff67fa5e8 int>
> constant 9>
> (gdb) call debug_tree (0x7ffff67fa5e8)
> Cannot resolve function debug_tree to any overloaded instance

Yeah, in the absence of overloads this is annoying.  Happens with 0, too.


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Richard Guenther]

On Wed, 15 Aug 2012, Diego Novillo wrote:

> On 12-08-15 07:59 , Richard Guenther wrote:
> 
> > (gdb) call debug_tree (*expr_p)
> >   <integer_cst 0x7ffff695d7c0 type <integer_type 0x7ffff67fa5e8 int>
> > constant 9>
> > (gdb) call debug_tree (0x7ffff67fa5e8)
> > Cannot resolve function debug_tree to any overloaded instance
> 
> Yeah, in the absence of overloads this is annoying.  Happens with 0, too.

0 is fixed if you have recent enough gdb.

(gdb) call debug_tree (0)

as 0 is a null pointer constant.

Richard.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-15 08:18 , Richard Guenther wrote:

> 0 is fixed if you have recent enough gdb.
>
> (gdb) call debug_tree (0)
>
> as 0 is a null pointer constant.

Oh, cool.  Progress.

GDB folks, would it be hard to figure out that there is a single variant 
of the called function and trust the user that they are passing the 
right pointer value?


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jan Kratochvil]

On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote:
> GDB folks, would it be hard to figure out that there is a single
> variant of the called function and trust the user that they are
> passing the right pointer value?

It is a needless violation of C++ resolving rules.  There are various easy way
how to get it working (in .gdbinit or cc1-gdb.gdb define GDB function, define
macro in GDB, use GDB python pretty printer instead (possibly even calling GCC
inferior function) etc.).

While I did not post such patch yet I would prefer to even forbid by default
expressions like
	(gdb) print *0x1234567
and enforce
	(gdb) print *(int *)0x1234567
instead as the former syntax confuses people (as commonly seen on IRC), the
same applies to calling functions without full debuginfo (they should require
an explicit cast in GDB) etc.


Regards,
Jan

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Michael Matz]

Hi,

On Wed, 15 Aug 2012, Jan Kratochvil wrote:

> It is a needless violation of C++ resolving rules.

It's not needless as the examples here show.  gdb is about helping people 
debug their stuff, not about language lawyering.

> There are various easy way how to get it working (in .gdbinit or 
> cc1-gdb.gdb define GDB function, define macro in GDB, use GDB python 
> pretty printer instead (possibly even calling GCC inferior function) 

We should define gdb macros for every not-overloaded function (which are 
_all_ GCC functions currently)?  Doesn't scale.


Ciao,
Michael.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jan Kratochvil]

Hi,

On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> It's not needless as the examples here show.  gdb is about helping people 
> debug their stuff, not about language lawyering.

In such case there should be a GDB setting for it as at least from my opinion
it complicates the debugging.  Then there may be different opinions what
should be the default.


Thanks,
Jan

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jakub Jelinek]

On Wed, Aug 15, 2012 at 05:49:34PM +0200, Jan Kratochvil wrote:
> On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> > On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> > It's not needless as the examples here show.  gdb is about helping people 
> > debug their stuff, not about language lawyering.
> 
> In such case there should be a GDB setting for it as at least from my opinion
> it complicates the debugging.  Then there may be different opinions what
> should be the default.

That would be fine for gcc development purposes.  We could switch that mode
on at the end of gcc .gdbinit .

	Jakub

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-15 11:44 , Michael Matz wrote:
> Hi,
>
> On Wed, 15 Aug 2012, Jan Kratochvil wrote:
>
>> It is a needless violation of C++ resolving rules.
>
> It's not needless as the examples here show.  gdb is about helping people
> debug their stuff, not about language lawyering.

Agreed.  If I'm passing a numeric pointer constant, I'm already past the 
bleeding edge.  I don't want gdb to get in the way.  If the inferior 
call crashes, I get to keep both pieces.


Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Tom Tromey]

>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:

Diego> GDB folks, would it be hard to figure out that there is a single
Diego> variant of the called function and trust the user that they are
Diego> passing the right pointer value?

I asked Keith to resurrect his patch for this.

Tom

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Gabriel Dos Reis]

On Wed, Aug 15, 2012 at 12:53 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:
>
> Diego> GDB folks, would it be hard to figure out that there is a single
> Diego> variant of the called function and trust the user that they are
> Diego> passing the right pointer value?
>
> I asked Keith to resurrect his patch for this.

Since people are concerned about typing rules, would it
be an option for GDB to allow people to input pointer
literals with the "p" suffix (or "0p" prefix instead of "0x")?

-- Gaby

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Tom Tromey]

>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

Tom> I asked Keith to resurrect his patch for this.

Gaby> Since people are concerned about typing rules, would it
Gaby> be an option for GDB to allow people to input pointer
Gaby> literals with the "p" suffix (or "0p" prefix instead of "0x")?

I think on the whole I'd rather have one extension instead of two.

It seems to me that the above would still require extensions in the
overloading code, to deal with conversions from void*; or perhaps some
magic pointer type.

What I think Keith is going to do is take his patch, change it so that
int->pointer conversions (if the int != 0) are given a different badness
from other conversions (meaning that, in theory, this should only be
chosen as a last resort, and shouldn't interfere with ordinary uses),
and finally add a parameter so that the feature can be disabled.

I hope this will be acceptable all around.

Tom

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Gabriel Dos Reis]

On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> Tom> I asked Keith to resurrect his patch for this.
>
> Gaby> Since people are concerned about typing rules, would it
> Gaby> be an option for GDB to allow people to input pointer
> Gaby> literals with the "p" suffix (or "0p" prefix instead of "0x")?
>
> I think on the whole I'd rather have one extension instead of two.

That is a fair point :-)

>
> It seems to me that the above would still require extensions in the
> overloading code, to deal with conversions from void*; or perhaps some
> magic pointer type.
>
> What I think Keith is going to do is take his patch, change it so that
> int->pointer conversions (if the int != 0) are given a different badness
> from other conversions (meaning that, in theory, this should only be
> chosen as a last resort, and shouldn't interfere with ordinary uses),
> and finally add a parameter so that the feature can be disabled.
>
> I hope this will be acceptable all around.

OK, that sounds reasonable.

Thanks!

-- Gaby

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Keith Seitz]

On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>>
>> Tom> I asked Keith to resurrect his patch for this.
[snip]
>> I hope this will be acceptable all around.
>
> OK, that sounds reasonable.

I have committed a patch which should allow you to do this and closed 
c++/13356. If there are any further problems/issues, please let me know.

We've re-purposed an old, unused option, "check type". This option does 
absolutely nothing in older versions of gdb, so setting it 
unconditionally is safe for all recent versions of gdb: "set check type 
off".

Keith

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz <keiths@redhat.com> wrote:
> On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
>>
>> On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>>>
>>>>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>>>
>>>
>>> Tom> I asked Keith to resurrect his patch for this.
>
> [snip]
>
>>> I hope this will be acceptable all around.
>>
>>
>> OK, that sounds reasonable.
>
>
> I have committed a patch which should allow you to do this and closed
> c++/13356. If there are any further problems/issues, please let me know.
>
> We've re-purposed an old, unused option, "check type". This option does
> absolutely nothing in older versions of gdb, so setting it unconditionally
> is safe for all recent versions of gdb: "set check type off".
>

Shouldn't it be added to GCC .gdbinit?

-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Mike Stump]

On Aug 15, 2012, at 4:59 AM, Richard Guenther wrote:
> and debugging becomes a nightmare (hello gdb people!)

> (gdb) call debug_tree (0x7ffff67fa5e8)
> Cannot resolve function debug_tree to any overloaded instance

Inquiring minds want to know if:

macro define debug_tree(A) ((tree)A)

makes the above work if you put it into gdbinit.in?  If yes, then, I think for now we should add such lines for every non-overloaded function, I too like using hex constants from dumps.  Oh, or, maybe we just add a debug_tree(long) overload just to satisfy gdb.