dtrace discuss - Aug 2005 - Best way to find function object offsets.

I am using the pid provider to debug some nasty race conditions that 
appear intermittently and then stick around, but never after the process
is restarted and never with debugging on. So, dtrace is ideal since I 
can wait until the problem happens and then start mucking about in the
process.

I spent the better part of today doing just that, and the better part of
the time I did spend was spent trying to calculate the function offsets
of the statements I wanted to trace.

So, my question is, this: is there any really clever way of doing this 
that doesn''t involve a lot of time with a hex calculator?  I used the 
dis command on the .o file, but the addresses I get are relative to the
beginning of the file, so I have to subtract the base address of the 
function for every statement I want to trace. Worse, I have no easy way 
to relate the assembly code to the c statements. I used the -S flag to 
cc and got .s file, but it has no addresses at all, and since the 
instructions generated by the compiler include pseudo-instructions, it 
is difficult to match them up with the dis output.

Of course, dbx will dis the area very nicely and with the offsets 
printed, but it has the same problem as the dis output, namely matching 
up the statement. And I am not sure if there is a easy way to get dbx to
dis an object in a single command, so it is not quite as easy to use as dis.

Now, I know that dbx will set break points based on c staements, so I 
know that the info is available. I just don''t know how to get at it.
Any
ideas?

Brian Utterback

Hi Brian,

The best way to do this is probably with mdb(1). Use gcore(1) to grab a
core file snapshot of the process and use mdb on the core or just
attach mdb to the running process with the -p option. In mdb do
something like this:
> main::dis
main:                           sethi     %hi(0x2000), %g1
main+4:                         xor       %g1, -0x210, %g1
main+8:                         save      %sp, %g1, %sp
main+0xc:                       sethi     %hi(0x5e800), %i5
main+0x10:                      st        %i0, [%fp + 0x44]
main+0x14:                      sethi     %hi(0x5e800), %i4

Hope that helps. I imagine the pid provider syntax shows our mdb bias.

We''re thinking about adding line number information to CTF so
specifying
line numbers may be possible in the future.

Adam

On Wed, Aug 10, 2005 at 07:12:21PM -0400, Brian Utterback
wrote:
> 
> I am using the pid provider to debug some nasty race conditions that 
> appear intermittently and then stick around, but never after the process
> is restarted and never with debugging on. So, dtrace is ideal since I 
> can wait until the problem happens and then start mucking about in the
> process.
> 
> I spent the better part of today doing just that, and the better part of
> the time I did spend was spent trying to calculate the function offsets
> of the statements I wanted to trace.
> 
> So, my question is, this: is there any really clever way of doing this 
> that doesn''t involve a lot of time with a hex calculator?  I used
the
> dis command on the .o file, but the addresses I get are relative to the
> beginning of the file, so I have to subtract the base address of the 
> function for every statement I want to trace. Worse, I have no easy way 
> to relate the assembly code to the c statements. I used the -S flag to 
> cc and got .s file, but it has no addresses at all, and since the 
> instructions generated by the compiler include pseudo-instructions, it 
> is difficult to match them up with the dis output.
> 
> Of course, dbx will dis the area very nicely and with the offsets 
> printed, but it has the same problem as the dis output, namely matching 
> up the statement. And I am not sure if there is a easy way to get dbx to
> dis an object in a single command, so it is not quite as easy to use as
dis.
> 
> Now, I know that dbx will set break points based on c staements, so I 
> know that the info is available. I just don''t know how to get at
it. Any
> ideas?
> 
> Brian Utterback
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

On Wed, Aug 10, 2005 at 07:12:21PM -0400, Brian Utterback
wrote:
> 
> So, my question is, this: is there any really clever way of doing this 
> that doesn''t involve a lot of time with a hex calculator?  I used
the
> dis command on the .o file, but the addresses I get are relative to the
> beginning of the file, so I have to subtract the base address of the 
> function for every statement I want to trace.
Unless you have stripped your binaries, /usr/ccs/bin/dis should display
addresses as ''function+offset''.
> Worse, I have no easy way 
> to relate the assembly code to the c statements. I used the -S flag to 
> cc and got .s file, but it has no addresses at all, and since the 
> instructions generated by the compiler include pseudo-instructions, it 
> is difficult to match them up with the dis output.
> 
> Of course, dbx will dis the area very nicely and with the offsets 
> printed, but it has the same problem as the dis output, namely matching 
> up the statement. And I am not sure if there is a easy way to get dbx to
> dis an object in a single command, so it is not quite as easy to use as
dis.
> 
> Now, I know that dbx will set break points based on c staements, so I 
> know that the info is available. I just don''t know how to get at
it. Any
> ideas?
This information is stored in the STABS and/or DWARF section of files if
you have enabled debugging (-g).  Neither dtrace, mdb, or dis understand
how to consume this debugging information.  Until we support either 
a) generating line number information as part of CTF or b) constructing
a library that understands STABS/DWARF as well as CTF, you''re stuck
using the dbx trick.  I believe the disassembler shipped as part of 
Sun Studio includes an option to annotate disassembly output with line
number information, but I''ve never used it.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock