* [PATCH] libiberty: support demangling of rvalue reference typenames
@ 2016-01-04 22:48 Artemiy Volkov
2016-01-05 6:06 ` Ian Lance Taylor
2016-05-18 21:52 ` Jeff Law
0 siblings, 2 replies; 10+ messages in thread
From: Artemiy Volkov @ 2016-01-04 22:48 UTC (permalink / raw)
To: gcc-patches; +Cc: dj, ian, Artemiy Volkov
This patch adds handling of 'O' (rvalue ref) type codes in the C++ demangling
code which is done similarly to the 'R' (regular references) case. It also adds
a few testcases for various demangling styles which are just mirrored versions
of the corresponding regular references demangling tests.
libiberty/ChangeLog:
2016-01-04 Artemiy Volkov <artemiyv@acm.org>
* cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
constant.
(demangle_template_value_parm): Handle tk_rvalue_reference
type kind.
(do_type): Support 'O' type id (rvalue references).
* testsuite/demangle-expected: Add tests.
---
libiberty/cplus-dem.c | 13 +++-
libiberty/testsuite/demangle-expected | 115 ++++++++++++++++++++++++++++++++++
2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/libiberty/cplus-dem.c b/libiberty/cplus-dem.c
index c68b981..122f05c 100644
--- a/libiberty/cplus-dem.c
+++ b/libiberty/cplus-dem.c
@@ -237,6 +237,7 @@ typedef enum type_kind_t
tk_none,
tk_pointer,
tk_reference,
+ tk_rvalue_reference,
tk_integral,
tk_bool,
tk_char,
@@ -2033,7 +2034,8 @@ demangle_template_value_parm (struct work_stuff *work, const char **mangled,
}
else if (tk == tk_real)
success = demangle_real_value (work, mangled, s);
- else if (tk == tk_pointer || tk == tk_reference)
+ else if (tk == tk_pointer || tk == tk_reference
+ || tk == tk_rvalue_reference)
{
if (**mangled == 'Q')
success = demangle_qualified (work, mangled, s,
@@ -3574,6 +3576,14 @@ do_type (struct work_stuff *work, const char **mangled, string *result)
tk = tk_reference;
break;
+ /* An rvalue reference type */
+ case 'O':
+ (*mangled)++;
+ string_prepend (&decl, "&&");
+ if (tk == tk_none)
+ tk = tk_rvalue_reference;
+ break;
+
/* An array */
case 'A':
{
@@ -3631,7 +3641,6 @@ do_type (struct work_stuff *work, const char **mangled, string *result)
break;
case 'M':
- case 'O':
{
type_quals = TYPE_UNQUALIFIED;
diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
index aebf01b..f947de7 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -31,6 +31,11 @@ ArrowLine::ArrowheadIntersects(Arrowhead *, BoxObj &, Graphic *)
ArrowLine::ArrowheadIntersects
#
--format=gnu --no-params
+ArrowheadIntersects__9ArrowLineP9ArrowheadO6BoxObjP7Graphic
+ArrowLine::ArrowheadIntersects(Arrowhead *, BoxObj &&, Graphic *)
+ArrowLine::ArrowheadIntersects
+#
+--format=gnu --no-params
AtEnd__13ivRubberGroup
ivRubberGroup::AtEnd(void)
ivRubberGroup::AtEnd
@@ -51,6 +56,11 @@ TextCode::CoreConstDecls(ostream &)
TextCode::CoreConstDecls
#
--format=gnu --no-params
+CoreConstDecls__8TextCodeO7ostream
+TextCode::CoreConstDecls(ostream &&)
+TextCode::CoreConstDecls
+#
+--format=gnu --no-params
Detach__8StateVarP12StateVarView
StateVar::Detach(StateVarView *)
StateVar::Detach
@@ -66,21 +76,41 @@ RelateManip::Effect(ivEvent &)
RelateManip::Effect
#
--format=gnu --no-params
+Effect__11RelateManipO7ivEvent
+RelateManip::Effect(ivEvent &&)
+RelateManip::Effect
+#
+--format=gnu --no-params
FindFixed__FRP4CNetP4CNet
FindFixed(CNet *&, CNet *)
FindFixed
#
--format=gnu --no-params
+FindFixed__FOP4CNetP4CNet
+FindFixed(CNet *&&, CNet *)
+FindFixed
+#
+--format=gnu --no-params
Fix48_abort__FR8twolongs
Fix48_abort(twolongs &)
Fix48_abort
#
--format=gnu --no-params
+Fix48_abort__FO8twolongs
+Fix48_abort(twolongs &&)
+Fix48_abort
+#
+--format=gnu --no-params
GetBarInfo__15iv2_6_VScrollerP13ivPerspectiveRiT2
iv2_6_VScroller::GetBarInfo(ivPerspective *, int &, int &)
iv2_6_VScroller::GetBarInfo
#
--format=gnu --no-params
+GetBarInfo__15iv2_6_VScrollerP13ivPerspectiveOiT2
+iv2_6_VScroller::GetBarInfo(ivPerspective *, int &&, int &&)
+iv2_6_VScroller::GetBarInfo
+#
+--format=gnu --no-params
GetBgColor__C9ivPainter
ivPainter::GetBgColor(void) const
ivPainter::GetBgColor
@@ -986,11 +1016,21 @@ List<VHDLEntity>::Pix::Pix(List<VHDLEntity>::Pix const &)
List<VHDLEntity>::Pix::Pix
#
--format=gnu --no-params
+__Q2t4List1Z10VHDLEntity3PixOCQ2t4List1Z10VHDLEntity3Pix
+List<VHDLEntity>::Pix::Pix(List<VHDLEntity>::Pix const &&)
+List<VHDLEntity>::Pix::Pix
+#
+--format=gnu --no-params
__Q2t4List1Z10VHDLEntity7elementRC10VHDLEntityPT0
List<VHDLEntity>::element::element(VHDLEntity const &, List<VHDLEntity>::element *)
List<VHDLEntity>::element::element
#
--format=gnu --no-params
+__Q2t4List1Z10VHDLEntity7elementOC10VHDLEntityPT0
+List<VHDLEntity>::element::element(VHDLEntity const &&, List<VHDLEntity>::element *)
+List<VHDLEntity>::element::element
+#
+--format=gnu --no-params
__Q2t4List1Z10VHDLEntity7elementRCQ2t4List1Z10VHDLEntity7element
List<VHDLEntity>::element::element(List<VHDLEntity>::element const &)
List<VHDLEntity>::element::element
@@ -1036,6 +1076,11 @@ PixX<VHDLLibrary, VHDLLibraryRep, List<VHDLEntity> >::PixX(PixX<VHDLLibrary, VHD
PixX<VHDLLibrary, VHDLLibraryRep, List<VHDLEntity> >::PixX
#
--format=gnu --no-params
+__t4PixX3Z11VHDLLibraryZ14VHDLLibraryRepZt4List1Z10VHDLEntityOCt4PixX3Z11VHDLLibraryZ14VHDLLibraryRepZt4List1Z10VHDLEntity
+PixX<VHDLLibrary, VHDLLibraryRep, List<VHDLEntity> >::PixX(PixX<VHDLLibrary, VHDLLibraryRep, List<VHDLEntity> > const &&)
+PixX<VHDLLibrary, VHDLLibraryRep, List<VHDLEntity> >::PixX
+#
+--format=gnu --no-params
nextE__C11VHDLLibraryRt4PixX3Z11VHDLLibraryZ14VHDLLibraryRepZt4List1Z10VHDLEntity
VHDLLibrary::nextE(PixX<VHDLLibrary, VHDLLibraryRep, List<VHDLEntity> > &) const
VHDLLibrary::nextE
@@ -1261,6 +1306,11 @@ smanip_int::smanip_int(ios &(*)(ios &, int), int)
smanip_int::smanip_int
#
--format=lucid --no-params
+__ct__10smanip_intFPFO3iosi_O3iosi
+smanip_int::smanip_int(ios &&(*)(ios &&, int), int)
+smanip_int::smanip_int
+#
+--format=lucid --no-params
__ct__11fstreambaseFi
fstreambase::fstreambase(int)
fstreambase::fstreambase
@@ -1281,6 +1331,11 @@ smanip_long::smanip_long(ios &(*)(ios &, long), long)
smanip_long::smanip_long
#
--format=lucid --no-params
+__ct__11smanip_longFPFO3iosl_O3iosl
+smanip_long::smanip_long(ios &&(*)(ios &&, long), long)
+smanip_long::smanip_long
+#
+--format=lucid --no-params
__ct__11stdiostreamFP4FILE
stdiostream::stdiostream(FILE *)
stdiostream::stdiostream
@@ -1321,6 +1376,11 @@ foo::foo(foo &)
foo::foo
#
--format=lucid --no-params
+__ct__3fooFO3foo
+foo::foo(foo &&)
+foo::foo
+#
+--format=lucid --no-params
__ct__3fooFi
foo::foo(int)
foo::foo
@@ -1336,6 +1396,11 @@ foo::foo(int, foo &, int, foo &, int, foo &)
foo::foo
#
--format=lucid --no-params
+__ct__3fooFiO3fooT1T2T1T2
+foo::foo(int, foo &&, int, foo &&, int, foo &&)
+foo::foo
+#
+--format=lucid --no-params
__ct__3iosFP9streambuf
ios::ios(streambuf *)
ios::ios
@@ -1811,6 +1876,11 @@ foo(int, foo &, int, foo &, int, foo &)
foo
#
--format=lucid --no-params
+foo__FiO3fooT1T2T1T2
+foo(int, foo &&, int, foo &&, int, foo &&)
+foo
+#
+--format=lucid --no-params
foo___3barFl
bar::foo_(long)
bar::foo_
@@ -2561,6 +2631,11 @@ DListNode<RLabel &>::DListNode(RLabel &, DListNode<RLabel &> *, DListNode<RLabel
DListNode<RLabel &>::DListNode
#
--format=arm --no-params
+__ct__25DListNode__pt__9_O6RLabelFO6RLabelP25DListNode__pt__9_O6RLabelT2
+DListNode<RLabel &&>::DListNode(RLabel &&, DListNode<RLabel &&> *, DListNode<RLabel &&> *)
+DListNode<RLabel &&>::DListNode
+#
+--format=arm --no-params
bar__3fooFiT16FooBar
foo::bar(int, int, FooBar)
foo::bar
@@ -2991,6 +3066,11 @@ DListNode<RLabel &>::DListNode(RLabel &, DListNode<RLabel &> *, DListNode<RLabel
DListNode<RLabel &>::DListNode
#
--format=hp --no-params
+__ct__9DListNodeXTO6RLabel__FO6RLabelP9DListNodeXTO6RLabel_T2
+DListNode<RLabel &&>::DListNode(RLabel &&, DListNode<RLabel &&> *, DListNode<RLabel &&> *)
+DListNode<RLabel &&>::DListNode
+#
+--format=hp --no-params
elem__6vectorXTiUP34__Fi
vector<int,34U>::elem(int)
vector<int,34U>::elem
@@ -3021,16 +3101,31 @@ vector<int,-67,4000U,short &>::elem(int)
vector<int,-67,4000U,short &>::elem
#
--format=hp --no-params
+elem__6vectorXTiSN67UP4000TOs__Fi
+vector<int,-67,4000U,short &&>::elem(int)
+vector<int,-67,4000U,short &&>::elem
+#
+--format=hp --no-params
elem__6vectorXTiSN67TRdTFPv_i__Fi
vector<int,-67,double &,int (void *)>::elem(int)
vector<int,-67,double &,int (void *)>::elem
#
--format=hp --no-params
+elem__6vectorXTiSN67TOdTFPv_i__Fi
+vector<int,-67,double &&,int (void *)>::elem(int)
+vector<int,-67,double &&,int (void *)>::elem
+#
+--format=hp --no-params
X__6vectorXTiSN67TdTPvUP5TRs
vector<int,-67,double,void *,5U,short &>::X
vector<int,-67,double,void *,5U,short &>::X
#
--format=hp --no-params
+X__6vectorXTiSN67TdTPvUP5TOs
+vector<int,-67,double,void *,5U,short &&>::X
+vector<int,-67,double,void *,5U,short &&>::X
+#
+--format=hp --no-params
elem__6vectorXTiA3foo__Fi
vector<int,&foo>::elem(int)
vector<int,&foo>::elem
@@ -3071,6 +3166,11 @@ Spec<int,int &,int>::spec(int *)
Spec<int,int &,int>::spec
#
--format=hp --no-params
+spec__17Spec<#1,#1.&&,#1>XTiTOiTi_FPi
+Spec<int,int &&,int>::spec(int *)
+Spec<int,int &&,int>::spec
+#
+--format=hp --no-params
add__XTc_FcT1
add<char>(char, char)
add<char>
@@ -3101,6 +3201,11 @@ C<Test, Test::output> call<Test>(Test &)
C<Test, Test::output> call<Test>
#
--format=gnu --no-params
+call__H1Z4Test_OX01_t1C2ZX01PMX01FPX01i_vQ2X016output
+C<Test, Test::output> call<Test>(Test &&)
+C<Test, Test::output> call<Test>
+#
+--format=gnu --no-params
fn__FPQ21n1cPMQ21n1cFPQ21n1c_i
fn(n::c *, int (n::c::*)(n::c *))
fn
@@ -3126,6 +3231,11 @@ int foo<TA<int const &, NA<9> > >(TA<int const &, NA<9> >)
int foo<TA<int const &, NA<9> > >
#
--format=gnu --no-params
+foo__H1Zt2TA2ZOCiZt2NA1Ui9_X01_i
+int foo<TA<int const &&, NA<9> > >(TA<int const &&, NA<9> >)
+int foo<TA<int const &&, NA<9> > >
+#
+--format=gnu --no-params
foo__H1Zt2TA2ZcZt2NA1Ui20_X01_i
int foo<TA<char, NA<20> > >(TA<char, NA<20> >)
int foo<TA<char, NA<20> > >
@@ -3402,6 +3512,11 @@ int* const volatile restrict _far
_Z3fooILi2EEvRAplT_Li1E_i
void foo<2>(int (&) [(2)+(1)])
foo<2>
+#
+--format=gnu-v3 --no-params
+_Z3fooILi2EEvOAplT_Li1E_i
+void foo<2>(int (&&) [(2)+(1)])
+foo<2>
#
--format=gnu-v3 --no-params
_Z1fM1AKFvvE
--
2.6.4
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-04 22:48 [PATCH] libiberty: support demangling of rvalue reference typenames Artemiy Volkov
@ 2016-01-05 6:06 ` Ian Lance Taylor
2016-01-05 7:57 ` Artemiy Volkov
2016-05-18 21:52 ` Jeff Law
1 sibling, 1 reply; 10+ messages in thread
From: Ian Lance Taylor @ 2016-01-05 6:06 UTC (permalink / raw)
To: Artemiy Volkov; +Cc: gcc-patches, dj
Artemiy Volkov <artemiyv@acm.org> writes:
> This patch adds handling of 'O' (rvalue ref) type codes in the C++ demangling
> code which is done similarly to the 'R' (regular references) case. It also adds
> a few testcases for various demangling styles which are just mirrored versions
> of the corresponding regular references demangling tests.
>
> libiberty/ChangeLog:
>
> 2016-01-04 Artemiy Volkov <artemiyv@acm.org>
>
> * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
> constant.
> (demangle_template_value_parm): Handle tk_rvalue_reference
> type kind.
> (do_type): Support 'O' type id (rvalue references).
Is there a compiler that actually generate these symbols?
Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 6:06 ` Ian Lance Taylor
@ 2016-01-05 7:57 ` Artemiy Volkov
2016-01-05 13:26 ` Ian Lance Taylor
0 siblings, 1 reply; 10+ messages in thread
From: Artemiy Volkov @ 2016-01-05 7:57 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-patches, dj
On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
> Artemiy Volkov <artemiyv@acm.org> writes:
>
> > This patch adds handling of 'O' (rvalue ref) type codes in the C++ demangling
> > code which is done similarly to the 'R' (regular references) case. It also adds
> > a few testcases for various demangling styles which are just mirrored versions
> > of the corresponding regular references demangling tests.
> >
> > libiberty/ChangeLog:
> >
> > 2016-01-04 Artemiy Volkov <artemiyv@acm.org>
> >
> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
> > constant.
> > (demangle_template_value_parm): Handle tk_rvalue_reference
> > type kind.
> > (do_type): Support 'O' type id (rvalue references).
>
> Is there a compiler that actually generate these symbols?
Sure, at least gcc and clang generate this. E.g. when compiling:
void f(int&& b) { }
you then have:
➜ nm 1.o
0000000000000000 T _Z1fOi
>
> Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 7:57 ` Artemiy Volkov
@ 2016-01-05 13:26 ` Ian Lance Taylor
2016-01-05 13:59 ` Artemiy Volkov
0 siblings, 1 reply; 10+ messages in thread
From: Ian Lance Taylor @ 2016-01-05 13:26 UTC (permalink / raw)
To: Artemiy Volkov; +Cc: gcc-patches, dj
Artemiy Volkov <artemiyv@acm.org> writes:
> On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
>> Artemiy Volkov <artemiyv@acm.org> writes:
>>
>> > This patch adds handling of 'O' (rvalue ref) type codes in the C++
>> > demangling
>> > code which is done similarly to the 'R' (regular references)
>> > case. It also adds
>> > a few testcases for various demangling styles which are just
>> > mirrored versions
>> > of the corresponding regular references demangling tests.
>> >
>> > libiberty/ChangeLog:
>> >
>> > 2016-01-04 Artemiy Volkov <artemiyv@acm.org>
>> >
>> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
>> > constant.
>> > (demangle_template_value_parm): Handle tk_rvalue_reference
>> > type kind.
>> > (do_type): Support 'O' type id (rvalue references).
>>
>> Is there a compiler that actually generate these symbols?
>
> Sure, at least gcc and clang generate this. E.g. when compiling:
>
> void f(int&& b) { }
>
> you then have:
>
> ➜ nm 1.o
> 0000000000000000 T _Z1fOi
That symbol name is handled by code in cp-demangle.c, not cplus-dem.c.
It already works today. Try it. cplus-dem is the old (very old)
demangler. cp-demangle is the current demangler.
Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 13:26 ` Ian Lance Taylor
@ 2016-01-05 13:59 ` Artemiy Volkov
2016-01-05 15:26 ` Ian Lance Taylor
0 siblings, 1 reply; 10+ messages in thread
From: Artemiy Volkov @ 2016-01-05 13:59 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-patches, dj
On Tue, Jan 05, 2016 at 05:26:28AM -0800, Ian Lance Taylor wrote:
> Artemiy Volkov <artemiyv@acm.org> writes:
>
> > On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
> >> Artemiy Volkov <artemiyv@acm.org> writes:
> >>
> >> > This patch adds handling of 'O' (rvalue ref) type codes in the C++
> >> > demangling
> >> > code which is done similarly to the 'R' (regular references)
> >> > case. It also adds
> >> > a few testcases for various demangling styles which are just
> >> > mirrored versions
> >> > of the corresponding regular references demangling tests.
> >> >
> >> > libiberty/ChangeLog:
> >> >
> >> > 2016-01-04 Artemiy Volkov <artemiyv@acm.org>
> >> >
> >> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
> >> > constant.
> >> > (demangle_template_value_parm): Handle tk_rvalue_reference
> >> > type kind.
> >> > (do_type): Support 'O' type id (rvalue references).
> >>
> >> Is there a compiler that actually generate these symbols?
> >
> > Sure, at least gcc and clang generate this. E.g. when compiling:
> >
> > void f(int&& b) { }
> >
> > you then have:
> >
> > ➜ nm 1.o
> > 0000000000000000 T _Z1fOi
>
> That symbol name is handled by code in cp-demangle.c, not cplus-dem.c.
> It already works today. Try it. cplus-dem is the old (very old)
> demangler. cp-demangle is the current demangler.
Sorry, I believe I should have mentioned that this patch is for the
needs of gdb, whose demangle command still pretty much uses the old
demangler in cplus-dem.c. I was working on rvalue references support in
gdb (https://sourceware.org/ml/gdb-patches/2015-12/msg00407.html) and
AIUI all the patches for libiberty should go through this mailing list,
that's why I sent the libiberty part here to later merge it to gdb.
>
> Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 13:59 ` Artemiy Volkov
@ 2016-01-05 15:26 ` Ian Lance Taylor
2016-01-05 20:38 ` Artemiy Volkov
0 siblings, 1 reply; 10+ messages in thread
From: Ian Lance Taylor @ 2016-01-05 15:26 UTC (permalink / raw)
To: Artemiy Volkov; +Cc: Ian Lance Taylor, gcc-patches, DJ Delorie
On Tue, Jan 5, 2016 at 5:59 AM, Artemiy Volkov <artemiyv@acm.org> wrote:
> On Tue, Jan 05, 2016 at 05:26:28AM -0800, Ian Lance Taylor wrote:
>> Artemiy Volkov <artemiyv@acm.org> writes:
>>
>> > On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
>> >> Artemiy Volkov <artemiyv@acm.org> writes:
>> >>
>> >> > This patch adds handling of 'O' (rvalue ref) type codes in the C++
>> >> > demangling
>> >> > code which is done similarly to the 'R' (regular references)
>> >> > case. It also adds
>> >> > a few testcases for various demangling styles which are just
>> >> > mirrored versions
>> >> > of the corresponding regular references demangling tests.
>> >> >
>> >> > libiberty/ChangeLog:
>> >> >
>> >> > 2016-01-04 Artemiy Volkov <artemiyv@acm.org>
>> >> >
>> >> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
>> >> > constant.
>> >> > (demangle_template_value_parm): Handle tk_rvalue_reference
>> >> > type kind.
>> >> > (do_type): Support 'O' type id (rvalue references).
>> >>
>> >> Is there a compiler that actually generate these symbols?
>> >
>> > Sure, at least gcc and clang generate this. E.g. when compiling:
>> >
>> > void f(int&& b) { }
>> >
>> > you then have:
>> >
>> > ➜ nm 1.o
>> > 0000000000000000 T _Z1fOi
>>
>> That symbol name is handled by code in cp-demangle.c, not cplus-dem.c.
>> It already works today. Try it. cplus-dem is the old (very old)
>> demangler. cp-demangle is the current demangler.
>
> Sorry, I believe I should have mentioned that this patch is for the
> needs of gdb, whose demangle command still pretty much uses the old
> demangler in cplus-dem.c. I was working on rvalue references support in
> gdb (https://sourceware.org/ml/gdb-patches/2015-12/msg00407.html) and
> AIUI all the patches for libiberty should go through this mailing list,
> that's why I sent the libiberty part here to later merge it to gdb.
If gdb is using the code in cplus-dem.c in any way for a program
compiled in the last 15 years, then gdb is doing something horribly
wrong. What function is gdb calling that makes your patch make a
difference?
Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 15:26 ` Ian Lance Taylor
@ 2016-01-05 20:38 ` Artemiy Volkov
2016-01-05 20:59 ` Ian Lance Taylor
0 siblings, 1 reply; 10+ messages in thread
From: Artemiy Volkov @ 2016-01-05 20:38 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Ian Lance Taylor, gcc-patches, DJ Delorie
On Tue, Jan 05, 2016 at 07:26:36AM -0800, Ian Lance Taylor wrote:
> On Tue, Jan 5, 2016 at 5:59 AM, Artemiy Volkov <artemiyv@acm.org> wrote:
> > On Tue, Jan 05, 2016 at 05:26:28AM -0800, Ian Lance Taylor wrote:
> >> Artemiy Volkov <artemiyv@acm.org> writes:
> >>
> >> > On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
> >> >> Artemiy Volkov <artemiyv@acm.org> writes:
> >> >>
> >> >> > This patch adds handling of 'O' (rvalue ref) type codes in the C++
> >> >> > demangling
> >> >> > code which is done similarly to the 'R' (regular references)
> >> >> > case. It also adds
> >> >> > a few testcases for various demangling styles which are just
> >> >> > mirrored versions
> >> >> > of the corresponding regular references demangling tests.
> >> >> >
> >> >> > libiberty/ChangeLog:
> >> >> >
> >> >> > 2016-01-04 Artemiy Volkov <artemiyv@acm.org>
> >> >> >
> >> >> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
> >> >> > constant.
> >> >> > (demangle_template_value_parm): Handle tk_rvalue_reference
> >> >> > type kind.
> >> >> > (do_type): Support 'O' type id (rvalue references).
> >> >>
> >> >> Is there a compiler that actually generate these symbols?
> >> >
> >> > Sure, at least gcc and clang generate this. E.g. when compiling:
> >> >
> >> > void f(int&& b) { }
> >> >
> >> > you then have:
> >> >
> >> > ➜ nm 1.o
> >> > 0000000000000000 T _Z1fOi
> >>
> >> That symbol name is handled by code in cp-demangle.c, not cplus-dem.c.
> >> It already works today. Try it. cplus-dem is the old (very old)
> >> demangler. cp-demangle is the current demangler.
> >
> > Sorry, I believe I should have mentioned that this patch is for the
> > needs of gdb, whose demangle command still pretty much uses the old
> > demangler in cplus-dem.c. I was working on rvalue references support in
> > gdb (https://sourceware.org/ml/gdb-patches/2015-12/msg00407.html) and
> > AIUI all the patches for libiberty should go through this mailing list,
> > that's why I sent the libiberty part here to later merge it to gdb.
>
> If gdb is using the code in cplus-dem.c in any way for a program
> compiled in the last 15 years, then gdb is doing something horribly
> wrong. What function is gdb calling that makes your patch make a
> difference?
This is what I'm doing, just the ordinary use of the demangle command...
➜ gdb gdb/gdb
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
[snip]
(top-gdb) b cplus-dem.c:3636
Breakpoint 3 at 0x8cf598: file ../../binutils-gdb/libiberty/cplus-dem.c,
line 3636.
(top-gdb) r
Starting program: /home/w41/gdb-build/gdb/gdb
[snip]
(gdb) demangle -l c++ -- __20DisplayList_IteratorO11DisplayList
Breakpoint 3, do_type (work=0x7fffffffdf40, mangled=0x7fffffffded0,
result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
3636 type_quals = TYPE_UNQUALIFIED;
(top-gdb) bt
#0 do_type (work=0x7fffffffdf40, mangled=0x7fffffffded0,
result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
#1 0x00000000008d0b5c in do_arg (work=0x7fffffffdf40,
mangled=0x7fffffffded0, result=0x7fffffffdde0)
at ../../binutils-gdb/libiberty/cplus-dem.c:4231
#2 0x00000000008d1350 in demangle_args (work=0x7fffffffdf40,
mangled=0x7fffffffded0, declp=0x7fffffffdee0)
at ../../binutils-gdb/libiberty/cplus-dem.c:4514
#3 0x00000000008cb79a in demangle_signature (work=0x7fffffffdf40,
mangled=0x7fffffffded0, declp=0x7fffffffdee0)
at ../../binutils-gdb/libiberty/cplus-dem.c:1665
#4 0x00000000008ca778 in internal_cplus_demangle (work=0x7fffffffdf40,
mangled=0xdf5132 "O11DisplayList")
at ../../binutils-gdb/libiberty/cplus-dem.c:1203
#5 0x00000000008c9e0c in cplus_demangle (mangled=0xdf511a
"__20DisplayList_IteratorO11DisplayList", options=3)
at ../../binutils-gdb/libiberty/cplus-dem.c:886
#6 0x00000000007f2af0 in bfd_demangle (abfd=0x0, name=0xdf511a
"__20DisplayList_IteratorO11DisplayList", options=3)
at ../../binutils-gdb/bfd/bfd.c:1917
#7 0x0000000000781795 in gdb_demangle (name=0xdf511a
"__20DisplayList_IteratorO11DisplayList", options=3)
at ../../binutils-gdb/gdb/cp-support.c:1571
#8 0x0000000000695474 in language_demangle (current_language=0x9c0180
<cplus_language_defn>,
mangled=0xdf511a "__20DisplayList_IteratorO11DisplayList",
options=3) at ../../binutils-gdb/gdb/language.c:651
#9 0x00000000006a9189 in demangle_command (args=0xdf61a9 "-l c++ --
__20DisplayList_IteratorO11DisplayList", from_tty=1)
at ../../binutils-gdb/gdb/demangle.c:218
#10 0x0000000000507d64 in do_cfunc (c=0xeb1710, args=0xdf61a9 "-l c++ --
__20DisplayList_IteratorO11DisplayList", from_tty=1)
at ../../binutils-gdb/gdb/cli/cli-decode.c:105
#11 0x000000000050ad01 in cmd_func (cmd=0xeb1710, args=0xdf61a9 "-l c++
-- __20DisplayList_IteratorO11DisplayList", from_tty=1)
at ../../binutils-gdb/gdb/cli/cli-decode.c:1885
#12 0x0000000000769272 in execute_command (p=0xdf61d8 "t", from_tty=1)
at ../../binutils-gdb/gdb/top.c:475
#13 0x00000000006558c7 in command_handler (command=0xdf61a0 "demangle -l
c++ -- __20DisplayList_IteratorO11DisplayList")
at ../../binutils-gdb/gdb/event-top.c:491
#14 0x0000000000655e80 in command_line_handler (rl=0x1161910 "demangle
-l c++ -- __20DisplayList_IteratorO11DisplayList")
at ../../binutils-gdb/gdb/event-top.c:690
#15 0x00000000007d73fb in rl_callback_read_char () at
../../binutils-gdb/readline/callback.c:220
#16 0x000000000065538f in rl_callback_read_char_wrapper
(client_data=0x0) at ../../binutils-gdb/gdb/event-top.c:171
#17 0x00000000006557f4 in stdin_event_handler (error=0, client_data=0x0)
at ../../binutils-gdb/gdb/event-top.c:430
#18 0x000000000065441f in handle_file_event (file_ptr=0x11602c0,
ready_mask=1) at ../../binutils-gdb/gdb/event-loop.c:708
#19 0x00000000006549c2 in gdb_wait_for_event (block=1) at
../../binutils-gdb/gdb/event-loop.c:834
#20 0x000000000065391c in gdb_do_one_event () at
../../binutils-gdb/gdb/event-loop.c:323
#21 0x000000000065395e in start_event_loop () at
../../binutils-gdb/gdb/event-loop.c:347
#22 0x00000000006553c2 in cli_command_loop (data=0x0) at
../../binutils-gdb/gdb/event-top.c:186
---Type <return> to continue, or q <return> to quit---
#23 0x000000000064bd26 in current_interp_command_loop () at
../../binutils-gdb/gdb/interps.c:317
#24 0x000000000064cf0a in captured_command_loop (data=0x0) at
../../binutils-gdb/gdb/main.c:318
#25 0x0000000000648b31 in catch_errors (func=0x64ceef
<captured_command_loop>, func_args=0x0, errstring=0x9863d5 "",
mask=RETURN_MASK_ALL)
at ../../binutils-gdb/gdb/exceptions.c:240
#26 0x000000000064e3f9 in captured_main (data=0x7fffffffe7e0) at
../../binutils-gdb/gdb/main.c:1157
#27 0x0000000000648b31 in catch_errors (func=0x64d321 <captured_main>,
func_args=0x7fffffffe7e0, errstring=0x9863d5 "", mask=RETURN_MASK_ALL)
at ../../binutils-gdb/gdb/exceptions.c:240
#28 0x000000000064e422 in gdb_main (args=0x7fffffffe7e0) at
../../binutils-gdb/gdb/main.c:1165
#29 0x0000000000468c0d in main (argc=1, argv=0x7fffffffe8e8) at
../../binutils-gdb/gdb/gdb.c:32
>
> Ian
Thanks,
Artemiy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 20:38 ` Artemiy Volkov
@ 2016-01-05 20:59 ` Ian Lance Taylor
2016-01-07 15:47 ` Artemiy Volkov
0 siblings, 1 reply; 10+ messages in thread
From: Ian Lance Taylor @ 2016-01-05 20:59 UTC (permalink / raw)
To: Artemiy Volkov; +Cc: Ian Lance Taylor, gcc-patches, DJ Delorie
On Tue, Jan 5, 2016 at 12:38 PM, Artemiy Volkov <artemiyv@acm.org> wrote:
> On Tue, Jan 05, 2016 at 07:26:36AM -0800, Ian Lance Taylor wrote:
>
>> If gdb is using the code in cplus-dem.c in any way for a program
>> compiled in the last 15 years, then gdb is doing something horribly
>> wrong. What function is gdb calling that makes your patch make a
>> difference?
>
> This is what I'm doing, just the ordinary use of the demangle command...
>
> ➜ gdb gdb/gdb
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> [snip]
> (top-gdb) b cplus-dem.c:3636
> Breakpoint 3 at 0x8cf598: file ../../binutils-gdb/libiberty/cplus-dem.c,
> line 3636.
> (top-gdb) r
> Starting program: /home/w41/gdb-build/gdb/gdb
> [snip]
> (gdb) demangle -l c++ -- __20DisplayList_IteratorO11DisplayList
>
> Breakpoint 3, do_type (work=0x7fffffffdf40, mangled=0x7fffffffded0,
> result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
> 3636 type_quals = TYPE_UNQUALIFIED;
> (top-gdb) bt
> #0 do_type (work=0x7fffffffdf40, mangled=0x7fffffffded0,
> result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
> #1 0x00000000008d0b5c in do_arg (work=0x7fffffffdf40,
> mangled=0x7fffffffded0, result=0x7fffffffdde0)
> at ../../binutils-gdb/libiberty/cplus-dem.c:4231
> #2 0x00000000008d1350 in demangle_args (work=0x7fffffffdf40,
> mangled=0x7fffffffded0, declp=0x7fffffffdee0)
> at ../../binutils-gdb/libiberty/cplus-dem.c:4514
> #3 0x00000000008cb79a in demangle_signature (work=0x7fffffffdf40,
> mangled=0x7fffffffded0, declp=0x7fffffffdee0)
> at ../../binutils-gdb/libiberty/cplus-dem.c:1665
> #4 0x00000000008ca778 in internal_cplus_demangle (work=0x7fffffffdf40,
> mangled=0xdf5132 "O11DisplayList")
> at ../../binutils-gdb/libiberty/cplus-dem.c:1203
> #5 0x00000000008c9e0c in cplus_demangle (mangled=0xdf511a
> "__20DisplayList_IteratorO11DisplayList", options=3)
> at ../../binutils-gdb/libiberty/cplus-dem.c:886
> #6 0x00000000007f2af0 in bfd_demangle (abfd=0x0, name=0xdf511a
> "__20DisplayList_IteratorO11DisplayList", options=3)
> at ../../binutils-gdb/bfd/bfd.c:1917
> #7 0x0000000000781795 in gdb_demangle (name=0xdf511a
> "__20DisplayList_IteratorO11DisplayList", options=3)
> at ../../binutils-gdb/gdb/cp-support.c:1571
> #8 0x0000000000695474 in language_demangle (current_language=0x9c0180
> <cplus_language_defn>,
> mangled=0xdf511a "__20DisplayList_IteratorO11DisplayList",
> options=3) at ../../binutils-gdb/gdb/language.c:651
> #9 0x00000000006a9189 in demangle_command (args=0xdf61a9 "-l c++ --
> __20DisplayList_IteratorO11DisplayList", from_tty=1)
> at ../../binutils-gdb/gdb/demangle.c:218
> #10 0x0000000000507d64 in do_cfunc (c=0xeb1710, args=0xdf61a9 "-l c++ --
> __20DisplayList_IteratorO11DisplayList", from_tty=1)
> at ../../binutils-gdb/gdb/cli/cli-decode.c:105
> #11 0x000000000050ad01 in cmd_func (cmd=0xeb1710, args=0xdf61a9 "-l c++
> -- __20DisplayList_IteratorO11DisplayList", from_tty=1)
> at ../../binutils-gdb/gdb/cli/cli-decode.c:1885
> #12 0x0000000000769272 in execute_command (p=0xdf61d8 "t", from_tty=1)
> at ../../binutils-gdb/gdb/top.c:475
> #13 0x00000000006558c7 in command_handler (command=0xdf61a0 "demangle -l
> c++ -- __20DisplayList_IteratorO11DisplayList")
> at ../../binutils-gdb/gdb/event-top.c:491
> #14 0x0000000000655e80 in command_line_handler (rl=0x1161910 "demangle
> -l c++ -- __20DisplayList_IteratorO11DisplayList")
Where is the symbol "__20DisplayList_IteratorO11DisplayList" coming from?
As far as I know no current C++ compiler will generate such a symbol.
Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-05 20:59 ` Ian Lance Taylor
@ 2016-01-07 15:47 ` Artemiy Volkov
0 siblings, 0 replies; 10+ messages in thread
From: Artemiy Volkov @ 2016-01-07 15:47 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Ian Lance Taylor, gcc-patches, DJ Delorie
On Tue, Jan 05, 2016 at 12:59:36PM -0800, Ian Lance Taylor wrote:
> On Tue, Jan 5, 2016 at 12:38 PM, Artemiy Volkov <artemiyv@acm.org> wrote:
> > On Tue, Jan 05, 2016 at 07:26:36AM -0800, Ian Lance Taylor wrote:
> >
> >> If gdb is using the code in cplus-dem.c in any way for a program
> >> compiled in the last 15 years, then gdb is doing something horribly
> >> wrong. What function is gdb calling that makes your patch make a
> >> difference?
> >
> > This is what I'm doing, just the ordinary use of the demangle command...
> >
> > ➜ gdb gdb/gdb
> > GNU gdb (GDB) 7.10.1
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > [snip]
> > (top-gdb) b cplus-dem.c:3636
> > Breakpoint 3 at 0x8cf598: file ../../binutils-gdb/libiberty/cplus-dem.c,
> > line 3636.
> > (top-gdb) r
> > Starting program: /home/w41/gdb-build/gdb/gdb
> > [snip]
> > (gdb) demangle -l c++ -- __20DisplayList_IteratorO11DisplayList
> >
> > Breakpoint 3, do_type (work=0x7fffffffdf40, mangled=0x7fffffffded0,
> > result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
> > 3636 type_quals = TYPE_UNQUALIFIED;
> > (top-gdb) bt
> > #0 do_type (work=0x7fffffffdf40, mangled=0x7fffffffded0,
> > result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
> > #1 0x00000000008d0b5c in do_arg (work=0x7fffffffdf40,
> > mangled=0x7fffffffded0, result=0x7fffffffdde0)
> > at ../../binutils-gdb/libiberty/cplus-dem.c:4231
> > #2 0x00000000008d1350 in demangle_args (work=0x7fffffffdf40,
> > mangled=0x7fffffffded0, declp=0x7fffffffdee0)
> > at ../../binutils-gdb/libiberty/cplus-dem.c:4514
> > #3 0x00000000008cb79a in demangle_signature (work=0x7fffffffdf40,
> > mangled=0x7fffffffded0, declp=0x7fffffffdee0)
> > at ../../binutils-gdb/libiberty/cplus-dem.c:1665
> > #4 0x00000000008ca778 in internal_cplus_demangle (work=0x7fffffffdf40,
> > mangled=0xdf5132 "O11DisplayList")
> > at ../../binutils-gdb/libiberty/cplus-dem.c:1203
> > #5 0x00000000008c9e0c in cplus_demangle (mangled=0xdf511a
> > "__20DisplayList_IteratorO11DisplayList", options=3)
> > at ../../binutils-gdb/libiberty/cplus-dem.c:886
> > #6 0x00000000007f2af0 in bfd_demangle (abfd=0x0, name=0xdf511a
> > "__20DisplayList_IteratorO11DisplayList", options=3)
> > at ../../binutils-gdb/bfd/bfd.c:1917
> > #7 0x0000000000781795 in gdb_demangle (name=0xdf511a
> > "__20DisplayList_IteratorO11DisplayList", options=3)
> > at ../../binutils-gdb/gdb/cp-support.c:1571
> > #8 0x0000000000695474 in language_demangle (current_language=0x9c0180
> > <cplus_language_defn>,
> > mangled=0xdf511a "__20DisplayList_IteratorO11DisplayList",
> > options=3) at ../../binutils-gdb/gdb/language.c:651
> > #9 0x00000000006a9189 in demangle_command (args=0xdf61a9 "-l c++ --
> > __20DisplayList_IteratorO11DisplayList", from_tty=1)
> > at ../../binutils-gdb/gdb/demangle.c:218
> > #10 0x0000000000507d64 in do_cfunc (c=0xeb1710, args=0xdf61a9 "-l c++ --
> > __20DisplayList_IteratorO11DisplayList", from_tty=1)
> > at ../../binutils-gdb/gdb/cli/cli-decode.c:105
> > #11 0x000000000050ad01 in cmd_func (cmd=0xeb1710, args=0xdf61a9 "-l c++
> > -- __20DisplayList_IteratorO11DisplayList", from_tty=1)
> > at ../../binutils-gdb/gdb/cli/cli-decode.c:1885
> > #12 0x0000000000769272 in execute_command (p=0xdf61d8 "t", from_tty=1)
> > at ../../binutils-gdb/gdb/top.c:475
> > #13 0x00000000006558c7 in command_handler (command=0xdf61a0 "demangle -l
> > c++ -- __20DisplayList_IteratorO11DisplayList")
> > at ../../binutils-gdb/gdb/event-top.c:491
> > #14 0x0000000000655e80 in command_line_handler (rl=0x1161910 "demangle
> > -l c++ -- __20DisplayList_IteratorO11DisplayList")
>
> Where is the symbol "__20DisplayList_IteratorO11DisplayList" coming from?
>
> As far as I know no current C++ compiler will generate such a symbol.
>
> Ian
Yeah, OK, thanks to your comments I can now see the problem with my
approach; everybody stopped using the old demangling style handled in
cplus-dem.c long before the rvalue references were introduced to C++.
There is therefore no need for this patch to libiberty.
Thank you for your help,
Artemiy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] libiberty: support demangling of rvalue reference typenames
2016-01-04 22:48 [PATCH] libiberty: support demangling of rvalue reference typenames Artemiy Volkov
2016-01-05 6:06 ` Ian Lance Taylor
@ 2016-05-18 21:52 ` Jeff Law
1 sibling, 0 replies; 10+ messages in thread
From: Jeff Law @ 2016-05-18 21:52 UTC (permalink / raw)
To: Artemiy Volkov, gcc-patches; +Cc: dj, ian
On 01/04/2016 06:43 PM, Artemiy Volkov wrote:
> 016-01-04 Artemiy Volkov <artemiyv@acm.org>
>
> * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
> constant.
> (demangle_template_value_parm): Handle tk_rvalue_reference
> type kind.
> (do_type): Support 'O' type id (rvalue references).
>
> * testsuite/demangle-expected: Add tests.
Thanks. I've installed this on the trunk after fixing some minor
whitespace issues.
jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-05-18 21:52 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-04 22:48 [PATCH] libiberty: support demangling of rvalue reference typenames Artemiy Volkov
2016-01-05 6:06 ` Ian Lance Taylor
2016-01-05 7:57 ` Artemiy Volkov
2016-01-05 13:26 ` Ian Lance Taylor
2016-01-05 13:59 ` Artemiy Volkov
2016-01-05 15:26 ` Ian Lance Taylor
2016-01-05 20:38 ` Artemiy Volkov
2016-01-05 20:59 ` Ian Lance Taylor
2016-01-07 15:47 ` Artemiy Volkov
2016-05-18 21:52 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).