|
From: Dennis L. <pla...@in...> - 2005-05-16 23:51:04
|
Hi, with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols not demangled. In one case it lloks just like a usual longer symbol : _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) while in the other case it has some _GLOBAL prefix : _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) is there any trick to get valgrind to demangling these symbols too ? greets Dennis |
|
From: Nicholas N. <nj...@cs...> - 2005-05-17 02:59:43
|
On Mon, 16 May 2005, Dennis Lubert wrote: > with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols > not demangled. In one case it lloks just like a usual longer symbol : > > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) > > while in the other case it has some _GLOBAL prefix : > > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > is there any trick to get valgrind to demangling these symbols too ? Does increasing M_VG_ERRTXT help? Probably not, but I can't think of anything else. N |
|
From: Julian S. <js...@ac...> - 2005-05-17 10:21:29
|
On Tuesday 17 May 2005 03:59, Nicholas Nethercote wrote: > On Mon, 16 May 2005, Dennis Lubert wrote: > > with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols > > not demangled. In one case it lloks just like a usual longer symbol : > > > > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ > >ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) > > > > while in the other case it has some _GLOBAL prefix : > > > > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > > > is there any trick to get valgrind to demangling these symbols too ? > > Does increasing M_VG_ERRTXT help? Probably not, but I can't think of > anything else. Valgrind just uses the standard GNU C++ demangler (c++filt) code. So first thing to try is to see if c++filt can make sense of either of these symbols (it can't). J |
|
From: Tom H. <to...@co...> - 2005-05-17 10:42:05
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Tuesday 17 May 2005 03:59, Nicholas Nethercote wrote:
>> On Mon, 16 May 2005, Dennis Lubert wrote:
>> > with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols
>> > not demangled. In one case it lloks just like a usual longer symbol :
>> >
>> > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_
>> >ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730)
>> >
>> > while in the other case it has some _GLOBAL prefix :
>> >
>> > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120)
>> >
>> > is there any trick to get valgrind to demangling these symbols too ?
>>
>> Does increasing M_VG_ERRTXT help? Probably not, but I can't think of
>> anything else.
>
> Valgrind just uses the standard GNU C++ demangler (c++filt) code.
> So first thing to try is to see if c++filt can make sense of
> either of these symbols (it can't).
My one can sort of handle the second one:
dellow [~] % c++filt
_GLOBAL__I__ZN5iwear4i18n17locale_code_tableE
global constructors keyed to _ZN5iwear4i18n17locale_code_tableE
Of course valgrind's copy of the demangler is fairly old now so we
might need to update it at some point.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-05-17 12:34:52
|
On Tue, 17 May 2005, Tom Hughes wrote: >>>> _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ >>>> ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) >>>> >>>> _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > My one can sort of handle the second one: > > dellow [~] % c++filt > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE > global constructors keyed to _ZN5iwear4i18n17locale_code_tableE And mine can handle the first, but not the second: [~] c++filt _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ std::_Rb_tree<char const*, std::pair<char const* const, iwear::iwear_language>, std::_Select1st<std::pair<char const* const, iwear::iwear_language> >, iwear::cstring_less, std::allocator<std::pair<char const* const, iwear::iwear_language> > >::_Rb_tree[in-charge](iwear::cstring_less const&, std::allocator<std::pair<char const* const, iwear::iwear_language> > const&) _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE I'm using GNU c++filt (C++ demangler), version 2.12.90.0.1 > Of course valgrind's copy of the demangler is fairly old now so we > might need to update it at some point. That could be it. Dennis, are you interested in taking a look to see if that's the case, ie. how it compares with an up-to-date GNU demangler? If you look at the 2.4 repository at KDE, look in coregrind/demangle/. If you look at the 3.0 repository at valgrind.org, look in coregrind/m_demangle/. The code within those directories is largely just a cut-and-paste job of the GNU demangler code, I believe. It might be instructive to first start by diff'ing Valgrind's code against the demangler code. Thanks. N |
|
From: Igmar P. <mai...@jd...> - 2005-05-17 13:17:24
|
> I'm using > > GNU c++filt (C++ demangler), version 2.12.90.0.1 The one that comes from binutils 2.15 / 2.16 seems to understand both, bot the second one doesn't look right to me. Regards, Igmar |
|
From: Julian S. <js...@ac...> - 2005-05-17 13:22:02
|
> That could be it. Dennis, are you interested in taking a look to see if > that's the case, ie. how it compares with an up-to-date GNU demangler? I'd second that -- pulling the demangler more up to date would be a really useful thing to do, if you have the enthusiasm. J |
|
From: Dennis L. <pla...@in...> - 2005-05-17 21:49:31
|
Am Dienstag, den 17.05.2005, 07:34 -0500 schrieb Nicholas Nethercote: > On Tue, 17 May 2005, Tom Hughes wrote: > > >>>> _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ > >>>> ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) > >>>> > >>>> _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > > > My one can sort of handle the second one: > > > > dellow [~] % c++filt > > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE > > global constructors keyed to _ZN5iwear4i18n17locale_code_tableE > > And mine can handle the first, but not the second: > > [~] c++filt > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ > std::_Rb_tree<char const*, std::pair<char const* const, iwear::iwear_language>, std::_Select1st<std::pair<char const* const, iwear::iwear_language> >, iwear::cstring_less, std::allocator<std::pair<char const* const, iwear::iwear_language> > >::_Rb_tree[in-charge](iwear::cstring_less const&, std::allocator<std::pair<char const* const, iwear::iwear_language> > const&) > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE > > I'm using > > GNU c++filt (C++ demangler), version 2.12.90.0.1 > > > Of course valgrind's copy of the demangler is fairly old now so we > > might need to update it at some point. > > That could be it. Dennis, are you interested in taking a look to see if > that's the case, ie. how it compares with an up-to-date GNU demangler? > > If you look at the 2.4 repository at KDE, look in coregrind/demangle/. > If you look at the 3.0 repository at valgrind.org, look in > coregrind/m_demangle/. The code within those directories is largely just > a cut-and-paste job of the GNU demangler code, I believe. It might be > instructive to first start by diff'ing Valgrind's code against the > demangler code. Thanks. Its interesting that even after >10 years of programming you always learn new things. I never had the need for using c++filt, thus did not know it existed. Im using 2.15.94.0.2.2 here from 20041220, and it demangles the first fine, and the second GLOBAL thing to : global constructors keyed to _ZN5iwear3uid6wehaveE and piping this a second time through c++filt gives global constructors keyed to iwear::uid::wehave So I think it needs a second pass to completely demangle. I currently have lots of things to do, but when I have time (or need something different to do ;) I will have a look at patching valgrind 2.4 svn version and send u the patch... greets Dennis |