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

Reply via email to