[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-dtrace-discuss
Subject:    Re: [dtrace-discuss] Nevada pid provider strangeness
From:       Jon Haslam <Jonathan.Haslam () Sun ! COM>
Date:       2008-07-04 13:35:52
Message-ID: 486E2738.8010708 () sun ! com
[Download RAW message or body]

Hi Chris,

Looks like this is being caused by the change to direct bindings
that happened in snv_83. Basically, when direct binding is specified
we get an implicit -z lazyload on the link so libraries that ON
tools link against are now are marked for lazy loading:

#elfdump -d /bin/getent

Dynamic Section:  .dynamic
     index  tag                value
       [0]  POSFLAG_1         0x1                 [ LAZY ]
       [1]  NEEDED            0x4ce               libsocket.so.1
       [2]  POSFLAG_1         0x1                 [ LAZY ]
       [3]  NEEDED            0x4f6               libnsl.so.1
       [4]  POSFLAG_1         0x1                 [ LAZY ]
       [5]  NEEDED            0x50b               libproject.so.1
       [6]  NEEDED            0x524               libc.so.1

As these libraries are not now loaded until explicitly referenced we don't
see them when we fire the process up as we used to prior to snv_83. The
workaround for you, as I said yesterday, is to use the '-Z' option. This
means that we carry on even if we don't match anything and we should get
a kick when the linker loads a library up and we check the incoming
library and see if it has anything we are interested in.

However, we don't seem to be getting that kick to evaluate a new library
under certain circumstances which I won't go into here. In the
short term, if you are using snv_83 and upwards and you suspect you are
not matching something that should be there, try disabling lazy loading
by exporting the LD_NOLAZYLOAD variable before firing up dtrace(1M).

Jon.

> On nevada build 93 if I specify anything other than a wild card for the pid \
> providers probefunc or probemod dtrace can't find the probes. 
> So with wild cards I get:
> 
> > enoexec.eu FSS 98 $; pfexec /usr/sbin/dtrace -n 'pid$target:::entry {
> @[probeprov, probemod, probefunc] = count()
> }' -c "getent hosts foobar" | grep gethostbyname
> dtrace: description 'pid$target:::entry ' matched 3413 probes
> dtrace: pid 26816 has exited
> pid26816                                            libnsl.so.1                     \
> _switch_gethostbyname_r                                           1 pid26816        \
> libnsl.so.1                                         gethostbyname                   \
> 1 pid26816                                            libnsl.so.1                   \
> gethostbyname_r                                                   1 : enoexec.eu \
> FSS 99 $;  
> bug specifying a probefunc:
> 
> > enoexec.eu FSS 101 $; pfexec /usr/sbin/dtrace -n \
> > 'pid$target::gethostbyname_r:entry {
> @[probeprov, probemod, probefunc] = count()
> }' -c "getent hosts foobar" | grep gethostbyname
> dtrace: invalid probe specifier pid$target::gethostbyname_r:entry {
> @[probeprov, probemod, probefunc] = count()
> }: probe description pid27710::gethostbyname_r:entry does not match any probes
> > enoexec.eu FSS 102 $; 
> 
> On solaris 10u3 it works.
> 
> 
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
> 

_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


[prev in list] [next in list] [prev in thread] [next in thread]