This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb
- From: Artemiy Volkov <artemiyv at acm dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Keith Seitz <keiths at redhat dot com>, "gdb-patches at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Tue, 19 Apr 2016 18:51:32 +0300
- Subject: Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb
- Authentication-results: sourceware.org; auth=none
- References: <1457147955-21871-1-git-send-email-artemiyv at acm dot org> <1458593958-25656-1-git-send-email-artemiyv at acm dot org> <56FD89F7 dot 1020409 at redhat dot com> <20160402084706 dot GD7371 at gmail dot com> <570402A1 dot 6030600 at redhat dot com> <20160406083016 dot GA31849 at gmail dot com> <570CE0B6 dot 8080707 at redhat dot com>
- Reply-to: artemiyv at acm dot org
Hi Pedro, sorry for the delay...
On Tue, Apr 12, 2016 at 2:49 PM, Pedro Alves <palves@redhat.com> wrote:
> I wouldn't want to generalize that assumption: C++11 is different enough that
> there's even been a need to break ABI. E.g., consider a test that involves
> printing or passing a std::string as param in an infcall; these may behave
> differently depending on C++ version. The ABI tags feature added to handle
> the ABI break also affect namespaces, parsing, and mangling handling in
> GDB, and can cause issues when code is compiled in C++11 mode, but not in
> C++03, and vice versa. On ABI tags issues, I'm thinking of PR19436 for example.
> So GDB needs to be able to debug code compiled with all C++ variants.
Yes, I agree. Adding -std=c++11 to the .exp files covering so much core
functionality wasn't right.
> I think we need to consider the pattern being introduced here, in general.
>
> For instance -- what will we do when we decide to test something
> C++14/C++17...-specific and find we could do that by just doing a
> small tweak to .cc file? Would we bump the testcase's C++ version, losing
> coverage of C++11 mode? In effect, that's what happened here.
> The only difference is that C++03 is feeling old by now, while C++17 feels
> too-new.
>
> However, C++03 is not old enough to be called "ancient" and "don't care",
> and what feels "new" is a moving target. Also, not sure all supported
> compilers accept "-std=gnu++11"; we may need to try compiling with
> different flags.
>
> How about something around this:
>
> - Don't pass any explicit -std flag in the .exp files at all.
> - Make these .exp tests gracefully cope with either C++03 or C++11, by
> skipping the C++11-specific parts when testing with C++03.
> - Run tests with CXX_FOR_TARGET="g++ -std=gnu++03"
> - Run tests with CXX_FOR_TARGET="g++ -std=gnu++11"
>
> After this is working, we could have these affected core-functionality
> tests themselves automatically run with multiple languages (c++03/c++11/...)
> That is, basically, we could factor the testcases to move their bodies to
> procedures taking a language version as parameter, and then have the testcases
> call the procedure multiple times.
>
> Alternatively, we could split the rvalue reference testing to separate
> files. My feeling is that it's a bit nicer that rvalue and lval reference
> testing is side by side in the same tests. But that might depend on the
> specific testcase. You'll have a better view into this here, though.
>
> WDYT?
>
Actually, this pattern has already been introduced: see
gdb.base/nested-subp[1-3].exp and gdb.cp/enum-class.exp. The authors of
these tests hardcoded the standard version in the additional_flags
variable. And I think this is the best way to go here -- IMO the cost of
the implementation you suggested outweighs the benefits. I understand the
idea of having the rvalue ref tests and the corresponding pointer/lvalue
ref tests next to each other, but that would cause too much pollution by
lots of "#ifdef __cplusplus >= ..." and reduced readability. And if we
group the rvalue ref tests together to make it just one #ifdef, why don't
we move those tests out to a separate file in the first place? Also, using
this scheme we would have to create a way to run only specific testcases
twice, which doesn't look like a clean solution, or maybe we'd have to run
the whole gdb.cp/* part of testsuite twice which would be unwarranted
waste of time. And people who want to run all of it using C++03 and C++11
stds can do it by hand.
So yeah, IMO the least of evils here would be to split rvalue reference
tests to separate files and to hardcode -std=gnu++11 in the .exp files.
This solution is much simpler, it keeps the source files clean, it assures
that each testcase will be run once (which is not a bad thing regarding
the time it takes to run the whole testsuite).
What do you say? Am I missing something?
Thanks,
Artemiy