On Wed, Mar 12, 2014 at 12:50 AM, Daniel O'Connor <[email protected]> wrote: > > On 12 Mar 2014, at 15:15, Prashanth Kumar <[email protected]> wrote: >> If you run >> # env DTRACE_DEBUG=1 dtrace -Ppid\$target -l -c ./static >> you will notice that lot of probe creation will fail, also no probes are >> created for instruction offsets. >> you will have to update the libproc library and fasttrap code to trace >> all the >> functions. > > I don't really care about the function offsets, just static functions. > > Or are you suggesting updating libproc and the fasttrap code will allow that > (as well as instruction offsets)?
I'd suggest updating to 9-STABLE. There have been quite a few fixes to fasttrap and libproc since 9.2. -Mark > > THanks. > >> -------------------------------------------- >> On Wed, 12/3/14, Daniel O'Connor <[email protected]> wrote: >> >> Subject: Re: dtracing static symbols >> To: "Robert Mustacchi" <[email protected]> >> Cc: [email protected] >> Date: Wednesday, 12 March, 2014, 2:54 AM >> >> >> On 12 Mar 2014, at 2:30, Robert Mustacchi <[email protected]> >> wrote: >>> On 03/10/2014 10:34 PM, Daniel O'Connor wrote: >>>> >>>> On 11 Mar 2014, at 15:34, Prashanth Kumar <[email protected]> >> wrote: >>>>> If the binary being traced has static symbols >> in its symbol table, DTrace should >>>>> be able to trace the function. Can you describe >> the example where you found this >>>>> difference in FreeBSD and OSX? >>>> >>>> Unfortunately the static symbols don't show up in >> the symbol table (as shown by nm). >>>> >>>> Is there a compile or link flag which will change >> that? >>> >>> Because it's a static function the compiler may inline >> it, which may be >>> why you don't actually see an entry in nm nor that it >> can be found by >>> DTrace. You'll want to look at the disassembled output >> of your program >>> to see if it was inlined. Different compilers can and >> will do different >>> things. There generally are flags you can pass to the >> compiler to tell >>> it not to inline it, but that's compiler specific. >> >> I just realised that my test contradicted the statement I >> made earlier.. >> However I checked my test program (static.c) and it the >> functions definitely appear in the symbol table. >> [mdtest 21:13] ~ >nm static|egrep '(foo|bar)' >> 0000000000400600 T bar >> 0000000000400620 t foo >> >> I also added the noinline attribute for good measure. >> >> It seems that _nothing_ shows up for executables, only >> shared libraries, this is OK for me since my code resides in >> a library but it is a bit surprised nonetheless.. >> >>>> (I'm not sure what the various numbers mean) >>> >>> The pid provider can instrument any instruction in a >> function, those are >>> the instruction offsets. >> >> Ahh, thanks. >> >> -- >> Daniel O'Connor software and network engineer >> for Genesis Software - http://www.gsoft.com.au >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 >> 7B3F CE8C >> >> >> >> >> >> >> >> > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "[email protected]"
