• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: gdb: "No line number information available for address...." :(
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gdb: "No line number information available for address...." :(


  • Subject: Re: gdb: "No line number information available for address...." :(
  • From: Jerry Krinock <email@hidden>
  • Date: Tue, 28 Jul 2009 20:02:43 -0700


On 2009 Jul 28, at 15:03, Jason Molenda wrote:

As Jonas suggested in his email, it's worthwhile to look at the ppc side of your dSYM as well to see what's in there - I'm specifying - arch i386 in all of these examples so you don't get confused by the presence of ppc debug info when you need i386 debug info.


Same "< EMPTY >" stuff if I specify ppc.

Either the app was built without debug information or the app was stripped before the GenerateDSYMFile. By the time dsymutil ran on Bookdog, the debug symbols were not present.

Makes sense -- I like it!

You can run dwarfdump on one of your .o files like we did with the dSYM earlier -- does it have any DWARF debug info in it?

Here we go:

dwarfdump --arch=i386 -r 0 "/Users/jk/Library/Application Support/ Xcode/IntermediateBuildFiles/Bookdog.build/Release/Bookdog.build/ Objects-normal/i386/BookdogController.o"
----------------------------------------------------------------------
File: /Users/jk/Library/Application Support/Xcode/ IntermediateBuildFiles/Bookdog.build/Release/Bookdog.build/Objects- normal/i386/BookdogController.o (architecture i386)
----------------------------------------------------------------------
.debug_info contents:


0x00000000: Compile Unit: length = 0x000121c4 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x000121c8)
...<snip> (There are a total of 2376 dots) </snip>...


I'm not sure if those 2376 dots are dwarfdump's way of displaying non- ASCII bytes?

Look for the Strip phase in your build log - is it happening before the GenerateDSYMFile?

I built again, but couldn't find an explicit "Strip" phase in my build transcript. Actually, even after modifying a .m file, I couldn't find a GenerateDSYMFile phase either. Should it be skipping these phases if there is a modified source file?


So, I did a "Clean". Then I built again. This time, my Build transcript shows GenerateDSYMFile happening near the middle, and "Stripping" is dead last.

Now, when I run dwarfdump --arch=i386 --debug-line, I get 144,007 lines. I see lots of file names, but no symbol names. A typical section is shown below [1].

And when I run dwarfdump --arch=i386 -r 0, I get 218 "Compile Unit" sections similar to the one above. It looks like maybe there is one "Compile Unit" for most every file in the code.

I still don't see any symbols, but apparently they are there, because the next thing I did was to purposely write a crasher into the code. Then I built again. Again, Build Transcript says that GenerateDSYMFile executed, as did Stripping (last, again). Then I ran the app, generated a crash report, asked gdb to symbolize an address from the report (even though it was already symbolized thanks to Crash Reporter's "magic"), and, voila, it gave me the symbol. Weird because the size of the Bookdog file in the .dSYM package is just a tad more, 3,254,939 bytes vs. 3,251,947 for the one that is "empty", and there have been other changes since then too.

Here are my conclusions so far:

   1.  Xcode *sometimes* does not generate a .dSYM file at all.
   2.  Xcode *sometimes* generates a .dSYM file which in fact has no
       symbols in it.  You would not suspect this from the .dSYM file
       size because it appears to be normal.  But Xcode does warn me
       that there are "no debug symbols in executable".
   3.  Xcode *sometimes* generates a .dSYM file with symbols in
       it, i.e. WORKS AS EXPECTED.

However, I have yet to discover the conditions which evoke outcome 1, 2 or 3. This is a mature product, and I'm doing bug fixes only -- I never touch the Build Settings, nor do I ever change the Active Configuration from Release. As far as the order of GenerateDSYMFile vs. Stripping, since I'm using Xcode I don't believe I have any control over that. I'm just a monkey, checking boxes in Build Settings :)

Jason, do you or anyone know why Xcode would sometimes give me an undesired outcome of either not generating a .dSYM file, or generating an empty one? I do not always do a Clean before my final Build. Is there a reason why that would be a good practice?

Sincerely,

Jerry Krinock


The best way to introspect this is to use otool, e.g. "otool -arch i386 -hlv Bookdog.app.dSYM/Contents/Resources/DWARF/Bookdog" you can skip down to the LC_SEGMENT load command for the __DWARF segment and see how much space all of the DWARF debug info is using.


I'll do that someday as a homework assignment.


[1]

----------------------------------------------------------------------
debug_line[0x00001278]
----------------------------------------------------------------------
Line table prologue:
total_length: 0x0000038d
version: 0x0002
prologue_length: 0x000001e3
min_inst_length: 0x01
default_is_stmt: 0x01
line_base: -10
line_range: 245
opcode_base: 0x0a
standard_opcode_lengths[ DW_LNS_copy ] = 0
standard_opcode_lengths[ DW_LNS_advance_pc ] = 1
standard_opcode_lengths[ DW_LNS_advance_line ] = 1
standard_opcode_lengths[ DW_LNS_set_file ] = 1
standard_opcode_lengths[ DW_LNS_set_column ] = 1
standard_opcode_lengths[ DW_LNS_negate_stmt ] = 0
standard_opcode_lengths[ DW_LNS_set_basic_block ] = 0
standard_opcode_lengths[ DW_LNS_const_add_pc ] = 0
standard_opcode_lengths[ DW_LNS_fixed_advance_pc ] = 1
include_directories[ 1] = '/Developer/SDKs/MacOSX10.4u.sdk/System/ Library/Frameworks/Foundation.framework/Headers'
include_directories[ 2] = '/Developer/SDKs/MacOSX10.4u.sdk/usr/include'
include_directories[ 3] = '/Developer/SDKs/MacOSX10.4u.sdk/usr/ include/i386'
include_directories[ 4] = '/Developer/SDKs/MacOSX10.4u.sdk/usr/ include/objc'
include_directories[ 5] = '/Users/jk/Documents/Programming/Projects/ Bookdog'
Dir Mod Time File Len File Name
---- ---------- ---------- ---------------------------
file_names[ 1] 5 0x00000000 0x00000000 BookdogArrayCategories.m
file_names[ 2] 2 0x00000000 0x00000000 i386/_types.h
file_names[ 3] 2 0x00000000 0x00000000 runetype.h
file_names[ 4] 2 0x00000000 0x00000000 objc/objc.h
file_names[ 5] 0 0x00000000 0x00000000 <built-in>
file_names[ 6] 1 0x00000000 0x00000000 NSObject.h
file_names[ 7] 1 0x00000000 0x00000000 NSArray.h
file_names[ 8] 1 0x00000000 0x00000000 NSArchiver.h
file_names[ 9] 1 0x00000000 0x00000000 NSObjCRuntime.h
file_names[ 10] 1 0x00000000 0x00000000 NSString.h
file_names[ 11] 1 0x00000000 0x00000000 NSValue.h
file_names[ 12] 5 0x00000000 0x00000000 BmItem.h
0x00001465: DW_LNE_set_address( 0x00005648 )
0x0000146c: DW_LNS_advance_line( 15 )
0x0000146e: address += 0, line += 0
0x0000000000005648 1 16 0


0x0000146f: DW_LNS_advance_line( 0 )
0x00001471: DW_LNS_advance_pc( 7 )
0x00001473: DW_LNS_copy
            0x000000000000564f      1     16      0

0x00001474: DW_LNS_advance_line( 3 )
0x00001476: DW_LNS_advance_pc( 3 )
0x00001478: DW_LNS_copy
            0x0000000000005652      1     19      0

<snip> And then there are dozens DW_LNS sections such as the above three sections
_______________________________________________
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
  • Follow-Ups:
    • Re: gdb: "No line number information available for address...." :(
      • From: Jason Molenda <email@hidden>
References: 
 >gdb: "No line number information available for address...." :( (From: Jerry Krinock <email@hidden>)
 >Re: gdb: "No line number information available for address...." :( (From: Jason Molenda <email@hidden>)
 >Re: gdb: "No line number information available for address...." :( (From: Jerry Krinock <email@hidden>)
 >Re: gdb: "No line number information available for address...." :( (From: Jason Molenda <email@hidden>)

  • Prev by Date: Re: C++ exception breakpoint failure
  • Next by Date: Re: gdb: "No line number information available for address...." :(
  • Previous by thread: Re: gdb: "No line number information available for address...." :(
  • Next by thread: Re: gdb: "No line number information available for address...." :(
  • Index(es):
    • Date
    • Thread