Thanks Jon. The bug report mentions that it might be possible to at
least increase the limit -- is there much hope for that? A lot of my
functions would be ok with an extra 10-20 chars. Also presumably the
limit exists in both the user-side and kernel-side components, so just
a rebuilt /usr/sbin/dtrace would not be enough to increase the limit?
No, unfortunately it wouldn't. You presume correctly though as the limit
is one that
cuts across kernel and user-land. Any form of fix, regardless of how
simple or
complex it may be, would require delivery of new user-land and kernel
components.
Jon.
Thanks,
Graham
*From:* dtrace-discuss-boun...@opensolaris.org
[mailto:dtrace-discuss-boun...@opensolaris.org] *On Behalf Of
*Jonathan Haslam
*Sent:* 12 July 2010 19:03
*To:* dtrace-discuss@opensolaris.org
*Subject:* Re: [dtrace-discuss] Length limit with probes in C++ functions
Hi Graham,
As far as I know, there isn't a lot you can do to work
around this issue apart from what you suggest; sorry
about that. For what it's worth, there is a bug logged to
track this:
6258412 DTrace needs to support longer function names
Jon.
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
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org <mailto:dtrace-discuss@opensolaris.org>
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
