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?
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