Graham Bennett
2010-07-12 13:14:41 UTC
Hi all,
A few years ago I remember having a discussion about an issue with probes on C++ functions where the mangled name exceeded a certain length, although I can't now find references to the problem with a quick google. I've recently started hitting this issue again so I was wondering if any workarounds have been discovered.
The problem seems to occur both with the pid provider and with USDT. Here's a USDT example if it's any help:
% cat mytest.d
provider mytest
{
probe myprobe();
};
% cat test.cpp
#include <string>
#include <vector>
#include <deque>
#include "mytest.h"
namespace Foo
{
#ifdef BIGTYPE
typedef std::vector<std::deque<std::string> > BigType;
#else
typedef int BigType;
#endif
void foo(const std::string&, const BigType&)
{
MYTEST_MYPROBE();
}
}
int main()
{
Foo::foo("foo", Foo::BigType());
}
Building without BIGTYPE defined works fine:
% dtrace -h -s mytest.d
% CC -c test.cpp
% dtrace -G -s mytest.d test.o
% CC -o test mytest.o test.o
% dtrace -n 'mytest$target:::myprobe { @[probefunc] = count(); }' -c./test | c++filt
dtrace: description 'mytest$target:::myprobe ' matched 1 probe
dtrace: pid 11254 has exited
void Foo::foo(const std::string &,const int&) 1
Building with it doesn't:
% CC -DBIGTYPE -c test.cpp
% dtrace -G -s mytest.d test.o
% CC -o test mytest.o test.o
Undefined first referenced
symbol in file
__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rkn0BGvector4n0BFdeque4n0E_n0BJallocator4n0E_____n mytest.o
ld: fatal: Symbol referencing errors. No output written to test
In the failing case mytest.o has an undefined reference to a truncated symbol:
% nm mytest.o| grep Foo
[44] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rkn0BGvector4n0BFdeque4n0E_n0BJallocator4n0E_____n
% nm test.o| grep Foo
[30] | 0| 10|FUNC |GLOB |0 |8 |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rkn0BGvector4n0BFdeque4n0E_n0BJallocator4n0E_____n0BJallocator4n0G______v_
In the working case there is no truncation:
% nm mytest.o| grep Foo
[40] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rki_v_
% nm test.o| grep Foo
[23] | 0| 10|FUNC |GLOB |0 |2 |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rki_v_
It would be great if anyone knows a way round this problem (other than changing function signatures!) as it really impacts on the usefulness of dtrace in a C++ environment.
Cheers,
Graham
A few years ago I remember having a discussion about an issue with probes on C++ functions where the mangled name exceeded a certain length, although I can't now find references to the problem with a quick google. I've recently started hitting this issue again so I was wondering if any workarounds have been discovered.
The problem seems to occur both with the pid provider and with USDT. Here's a USDT example if it's any help:
% cat mytest.d
provider mytest
{
probe myprobe();
};
% cat test.cpp
#include <string>
#include <vector>
#include <deque>
#include "mytest.h"
namespace Foo
{
#ifdef BIGTYPE
typedef std::vector<std::deque<std::string> > BigType;
#else
typedef int BigType;
#endif
void foo(const std::string&, const BigType&)
{
MYTEST_MYPROBE();
}
}
int main()
{
Foo::foo("foo", Foo::BigType());
}
Building without BIGTYPE defined works fine:
% dtrace -h -s mytest.d
% CC -c test.cpp
% dtrace -G -s mytest.d test.o
% CC -o test mytest.o test.o
% dtrace -n 'mytest$target:::myprobe { @[probefunc] = count(); }' -c./test | c++filt
dtrace: description 'mytest$target:::myprobe ' matched 1 probe
dtrace: pid 11254 has exited
void Foo::foo(const std::string &,const int&) 1
Building with it doesn't:
% CC -DBIGTYPE -c test.cpp
% dtrace -G -s mytest.d test.o
% CC -o test mytest.o test.o
Undefined first referenced
symbol in file
__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rkn0BGvector4n0BFdeque4n0E_n0BJallocator4n0E_____n mytest.o
ld: fatal: Symbol referencing errors. No output written to test
In the failing case mytest.o has an undefined reference to a truncated symbol:
% nm mytest.o| grep Foo
[44] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rkn0BGvector4n0BFdeque4n0E_n0BJallocator4n0E_____n
% nm test.o| grep Foo
[30] | 0| 10|FUNC |GLOB |0 |8 |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rkn0BGvector4n0BFdeque4n0E_n0BJallocator4n0E_____n0BJallocator4n0G______v_
In the working case there is no truncation:
% nm mytest.o| grep Foo
[40] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rki_v_
% nm test.o| grep Foo
[23] | 0| 10|FUNC |GLOB |0 |2 |__1cDFooDfoo6FrknDstdMbasic_string4Ccn0BLchar_traits4Cc__n0BJallocator4Cc____rki_v_
It would be great if anyone knows a way round this problem (other than changing function signatures!) as it really impacts on the usefulness of dtrace in a C++ environment.
Cheers,
Graham