dtrace discuss - Dec 2006 - List of all kernel functions

Hi,
How can I instruct dtrace to list all kernel functions, starting from a prob
that fires on a condition that I''ll supply and ending with another prob
that fires on another condition that I''ll supply?
For example, suppose I have a probe that fires on entry to kernel function A and
another probe that fires on entry to kernel function Z.
I''d like dtrace to list all kernel functions that had been called
between A and Z.
Thanks in advance.
 
 
This message posted from opensolaris.org

Shahar writes:
> Hi,
> How can I instruct dtrace to list all kernel functions, starting from a
prob that fires on a condition that I''ll supply and ending with another
prob that fires on another condition that I''ll supply?
> For example, suppose I have a probe that fires on entry to kernel function
A and another probe that fires on entry to kernel function Z.
> I''d like dtrace to list all kernel functions that had been called
between A and Z.
Assuming you''re talking about all of the functions called on a single
thread (not globally):

fbt::A:entry
{
	self->trace = 1;
}

fbt:::
/self->trace/
{
}

fbt::Z:entry
{
	self->trace = 0;
}

-- 
James Carlson, KISS Network                    <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Hi James,

Thanks for the quick reply.
Unfortunately I can''t use the fbt provider with my module since its
TEXT size is huge (output of size -f command: 6189076(.text) + 114932(.rodata) +
1492474(.rodata1) + 438320(.data) + 119091(.data1) + 1574132(.bss) = 9928025)
Is there another option without using the fbt provider?

Thanks,
Shahar.
 
 
This message posted from opensolaris.org

Shahar wrote:
> Unfortunately I can''t use the fbt provider with my module since
its TEXT size is huge (output of size -f command: 6189076(.text) +
114932(.rodata) + 1492474(.rodata1) + 438320(.data) + 119091(.data1) +
1574132(.bss) = 9928025)
Did you try it?
What error did you get?

- Jeremy

>Hi James,
>
>Thanks for the quick reply.
>Unfortunately I can''t use the fbt provider with my module since its
TEXT size is huge (output of s
ize -f command: 6189076(.text) + 114932(.rodata) + 1492474(.rodata1) +
438320(.data) + 119091(.data1) + 1574132(.bss) = 9928025)

Wow!  What the "f" does it do?

Casper

> Thanks for the quick reply.
> Unfortunately I can''t use the fbt provider with my module since
its TEXT size is huge (output of size -f command: 6189076(.text) +
114932(.rodata) + 1492474(.rodata1) + 438320(.data) + 119091(.data1) +
1574132(.bss) = 9928025)
> Is there another option without using the fbt provider?
Is this on SPARC or x86?  Either way, that''s one big honkin''
text segment!
That''s bigger (way bigger) than the "unix" and
"genunix" modules, and about
the same size as the entire Solaris kernel.  As you must realize, you
won''t be able to instrument that with FBT on SPARC -- the size of your
text segment exceeds the size of a branch displacement.  On x86, however,
you should be able to instrument it (we use traps instead of branches 
to instrument x86).  So your choices are, in order of difficulty:

  (1)  Use Solaris on x86, and instrument your module with FBT.

  (2)  See if a large amount of dead text has been erroneously compiled into
       your module, eliminate the dead text and use FBT on SPARC.

  (3)  Break-up your module into more reasonably sized components and use
       FBT on SPARC.

Good luck -- and hopefully you can use DTrace on x86 to find the dead code in
your whale of a module... ;)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

Bryan Cantrill wrote:
>   (2)  See if a large amount of dead text has been erroneously compiled
into
>        your module, eliminate the dead text and use FBT on SPARC.
You might try ld(1)''s -zignore option when building your app.

But, to get the full benefit of this option, you might have to do a
little work.  Typically, when you build an application, all global
symbols remain global.  This allows shared libraries to call back
into these interfaces.  However, most global symbols aren''t used
by any dependencies, and can be safely demoted to locals.

Once you''ve defined your public interface, ld(1) can help to
determine that all implementation symbols are contributing to
these public interfaces.  If they are not, you have dead code.

You can start of by inspecting some debugging output:

  % cat main.c
  void main(){}
  % cat foo.c
  void foo(){}
  % cat bar.c
  void bar(){}
  % cat mapfile
  {
         global:
                 foo;
         local:
                 *;
  };
  % LD_OPTIONS=-Dunused,detail cc -o main main.c foo.c bar.c -Mmapfile
  ...
  debug: section=.text; size=0x28; input from file=bar.o; unused: does \
  not satisfy any references

If you add the -zignore option, this dead section will be removed from
the link-edit.

Note, there are limitations to ld(1)''s capabilities.  If you have
multiple functions/data within the same file, ld(1) can''t separate any
dead items, as the compilers have already joined the individual items
into one .text or .data block.   You might try experimenting with the
compilers -xF options - these cause the generation of separate .text and
.data items which ld(1) can then work on - however, given the size of
your object, I wouldn''t be surprised if you break some other internal
limitation of the tool-chain :-)

Also, ld(1) can''t (yet) unravel cyclic dependencies within modules.
So, if foo() references bar() and bar() references foo() - or more
complex references that result in a cycle - ld(1) thinks everything
is being used.

I usually find that by applying -Dunused,detail, and then removing the
dead code that has been called out, you can rerun the experiment and
keep culling code from your app.

Whether any of this will reduce *your* text section enough ... I dunno.

And, you think you have problems?

% size -f a.o*
6021412(.hash) + 12042720(.dynsym) + 30802462(.dynstr) + 72(.rela.rodata) + 
3649392(.rela.got) + 183180(.rela.data) + 799584(.rela.picdata) + 
308340(.rela.plt) + 34168080(.text) + 29292376(.rodata1) + 4632501(.rodata) + 
10872(.SUNW_move) + 1216468(.got) + 308392(.plt) + 168(.dynamic) + 
4948693(.data1) + 99442053(.data) + 2411728(.picdata) + 17104972(.bss) =
247343465

There are companies out there that continually challenge the scaling
capabilities of ld(1) :-)

-- 
Rod