This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Support C++11 rvalue (move constructor)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Date: Wed, 16 Oct 2013 15:32:45 +0200
- Subject: Re: [patch] Support C++11 rvalue (move constructor)
- Authentication-results: sourceware.org; auth=none
- References: <20131012152836 dot GA9438 at host2 dot jankratochvil dot net> <87fvs33kb7 dot fsf at fleche dot redhat dot com> <20131014175747 dot GA9176 at host2 dot jankratochvil dot net> <87hacj1zsk dot fsf at fleche dot redhat dot com>
On Mon, 14 Oct 2013 20:18:51 +0200, Tom Tromey wrote:
> >> Is that also true for inferior calls?
> >> I didn't look.
>
> Jan> GDB cannot call constructors so this is irrelevant now.
>
> I'm not sure constructors matter. rvalue references affect overloading,
> e.g.:
>
> #include <stdio.h>
>
> int ov(int &x) { return 0; }
> int ov(int &&x) { return 1; }
>
> int main() {
> int z = 23;
> printf ("%d %d\n", ov(z), ov(23));
> }
OK, true. I see && already works fine due to the C++11 libiberty/ demangler.
(gdb) complete p 'ov
p 'ov(int&&)
p 'ov(int&)
Just inferior calls pick randomly the function depending on their order in
source (in DWARF):
(gdb) p ov(z)
$1 = 0
vs.
(gdb) p ov(z)
$1 = 1
This means we should really have two distinct TYPE_CODEs and then properly
select lvalue vs. rvalue function depending on the type of argument used passed
for the inferior call. Possibly failing to find the function if function only
accepts rvalue but user passes in real variable (lvalue).
The patch is definitely incorrect as is but I would say it is better than
nothing. The proper rvalue implementation is some work and I would say I have
other work to do.
> Tom> Maybe the size increase isn't that important.
>
> Jan> I always thought the opposite is true.
> Jan> Due to CU expansion with <tab> after some completions one easily gets to
> Jan> 1GB GDB and more (but IMO this is a bug <tab> should not expand CUs).
>
> I think what's missing is an idea of the amount that struct main_type
> contributes.
>
> My recollection is that I concluded that shrinking types wasn't
> worthwhile. However, it's worthwhile to redo the experiment, at least
> if you plan to completely fix this problem.
I find clear the <tab> CU expansion should be fixed. Then maybe GDB stops
growing. Or maybe not (and then one has to look more at main_type...).
Jan