thr3ads.net - dtrace discuss - [dtrace-discuss] Length limit with probes in C++ functions [Jul 2010]

If this information is useful, please help other people find it:
Share via:

Graham Bennett

2010-Jul-12 13:14 UTC

[dtrace-discuss] Length limit with probes in C++ functions

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100712/80536f6d/attachment.html>

Jonathan Haslam

2010-Jul-12 18:03 UTC

head link

[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 at opensolaris.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100712/f30364f5/attachment-0001.html>

Graham Bennett

2010-Jul-12 18:35 UTC

head link

[dtrace-discuss] Length limit with probes in C++ functions

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-bounces at opensolaris.org [mailto:dtrace-discuss-bounces
at opensolaris.org] On Behalf Of Jonathan Haslam
Sent: 12 July 2010 19:03
To: dtrace-discuss at 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 at opensolaris.org<mailto:dtrace-discuss at
opensolaris.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100712/b5802568/attachment.html>

Jonathan Haslam

2010-Jul-13 11:57 UTC

head link

[dtrace-discuss] Length limit with probes in C++ functions

> 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-bounces at opensolaris.org 
> [mailto:dtrace-discuss-bounces at opensolaris.org] *On Behalf Of 
> *Jonathan Haslam
> *Sent:* 12 July 2010 19:03
> *To:* dtrace-discuss at 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 at opensolaris.org  <mailto:dtrace-discuss at
opensolaris.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100713/30427f17/attachment-0001.html>

dtrace discuss - Jul 2010 - Length limit with probes in C++ functions

[dtrace-discuss] Length limit with probes in C++ functions

[dtrace-discuss] Length limit with probes in C++ functions

[dtrace-discuss] Length limit with probes in C++ functions

[dtrace-discuss] Length limit with probes in C++ functions