Re: Shark is losing source code
Re: Shark is losing source code
- Subject: Re: Shark is losing source code
- From: Jim Ingham <email@hidden>
- Date: Fri, 6 Jun 2008 11:50:49 -0700
At this point, it might be good to make sure you actually are getting
the debug information you think you are. If you want to check whether
your dSYM file actually has the info for the source files you are
missing in Shark, try something like (replacing "top" for whatever
your missing source file names are):
$ dwarfdump -x -r 0 -n 'top\.c' gdb.dSYM/
----------------------------------------------------------------------
File: gdb.dSYM/Contents/Resources/DWARF/gdb (architecture i386)
----------------------------------------------------------------------
Searching .debug_info data for names that match (case sensitive) the
regular expression 'top\.c'...
found 2 matches:
.debug_info contents for DIE entry at .debug_info[0x0005c649]
recursing 0 levels deep.
0x0005c649: TAG_compile_unit [1] *
AT_producer( "GNU C 4.2.1 (Apple Inc. build 5600)" )
AT_language( DW_LANG_C89 )
AT_name( "../../gdb/src/gdb/top.c" )
AT_comp_dir( "/Volumes/ThePlayground/Users/jingham/Work/
gdb-sources/tot-new-co/build/gdb" )
AT_low_pc( 0x00177b2b )
AT_high_pc( 0x0017a32e )
AT_stmt_list( 0x0001026b )
----------------------------------------------------------------------
.debug_info contents for DIE entry at .debug_info[0x0006baf6]
recursing 0 levels deep.
0x0006baf6: TAG_compile_unit [1] *
AT_producer( "GNU C 4.0.1 (Apple Inc. build 5478)" )
AT_language( DW_LANG_C89 )
AT_name( "../../gdb/src/gdb/event-top.c" )
AT_comp_dir( "/Volumes/ThePlayground/Users/jingham/Work/
gdb-sources/tot-new-co/build/gdb" )
AT_low_pc( 0x000a5d25 )
AT_high_pc( 0x000a7d40 )
If the source files you were expecting to see don't show up in this
search, then somewhere along the way the debug information is getting
stripped out before the dSYM is getting made (or it wasn't built -g to
begin with).
Of if you have an address that you think should have some associated
debug information, you can do:
$ dwarfdump --lookup 0x2727 gdb.dSYM
----------------------------------------------------------------------
File: gdb.dSYM/Contents/Resources/DWARF/gdb (architecture i386)
----------------------------------------------------------------------
Looking up address: 0x0000000000002727 in the debug information...found!
0x00000000: Compile Unit: length = 0x000000d4 version = 0x0002
abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x000000d8)
0x0000000b: TAG_compile_unit [1] *
AT_producer( "GNU C 4.2.1 (Apple Inc. build 5600)" )
AT_language( DW_LANG_C89 )
AT_name( "../../gdb/src/gdb/gdb.c" )
AT_comp_dir( "/Volumes/ThePlayground/Users/jingham/Work/
gdb-sources/tot-new-co/build/gdb" )
AT_low_pc( 0x0000271a )
AT_high_pc( 0x0000276f )
AT_stmt_list( 0x00000000 )
0x0000008f: TAG_subprogram [7] *
AT_external( 0x01 )
AT_name( "main" )
AT_decl_file( 0x01 )
AT_decl_line( 0x1c )
AT_prototyped( 0x01 )
AT_type( {0x00000025} ( int ) )
AT_low_pc( 0x0000271a )
AT_high_pc( 0x0000276f )
AT_frame_base( 0x00000000
0x0000271a - 0x0000271b: breg4 +4
0x0000271b - 0x0000271d: breg4 +8
0x0000271d - 0x0000276f: breg5 +8 )
AT_sibling( {0x000000d7} )
Line table dir : '../../gdb/src/gdb'
Line table file: 'gdb.c' line 30, column 0 with start address
0x0000000000002727
Note if your code is in a shared library or you are building a PIE
executable, you're going to have to figure out the load address of
your library and subtract that from the address Shark reports before
doing the computation.
Again if this doesn't show up, you build process isn't getting all the
debug info you need, and you're going to have to do some detective
work in the "build results" output.
Jim
On Jun 6, 2008, at 11:13 AM, kwiley wrote:
On Jun 5, 2008, at 5:56 PM, Rick Altherr wrote:
On Jun 5, 2008, at 4:06 PM, kwiley wrote:
Is this the right group to post Shark questions to?
My code was built with -O -g -DNDEBUG, although note that I have
the exact same problem if I build with -g alone.
I run my executable with Shark, wait for it, and get the typical
Shark results. I double-click various rows in the profile view to
see the associated code. Now, the weird part is that for *some*
files it shows the code, but for others it only shows the
assembly. If I look at the build transcript, the files in
question were definitely built with -g.
This is a rather peculiar build I admit, because it is an external
target that invokes make and basically doesn't use Xcode for much
other than editing, but nevertheless, what's going on?
I realize this post probably isn't sufficient to solve the
problem, but does anyone know how I should start working on this?
I don't really have any ideas?
Thanks.
As a workaround, you can use dsymutil to generate a .dSYM file.
The .dSYM is essentially an aggregation of all the debug
information contained in the .o's. If you generate one
successfully and place it in the same folder as the executable,
Shark will automatically read the debug information from
the .dSYM. This can be used to work around the .a bug in Shark.
--
Rick Altherr
Architecture and Performance Group
email@hidden
Are there any circumstances under which the dsymutil approach would
not work...because I tried it. :-) I ran it on the executable and
it produces a .dSYM file next to the executable. Shark's behavior
didn't change, it still showed only assembly for some of the
functions. Does that make sense?
________________________________________________________________________
Keith Wiley email@hidden http://www.cs.unm.edu/~kwiley
"I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forgo their use."
-- Galileo Galilei
________________________________________________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden