Created attachment 14038 [details] Example C code that demonstrates the issue When I compile the attached code, the "args_" argument to "Khandle_missed_dispatchVKgI" is missing a DW_AT_location. This is a test case isolated from a much larger body of code (where this happens more often). This code is also generated from our C back-end. It is interesting (to me at least) that the code generated by our LLVM back-end has the same problem. I compile with clang 3.5, 3.6 or the most recent release from Apple: clang -arch i386 -g -O -c -o bad-debug-info.o bad-debug-info.c and then I run dwarfdump (or llvm-dwarfdump) and see: 0x000005f4: DW_TAG_subprogram [18] * DW_AT_low_pc [DW_FORM_addr] (0x0000000000000030) DW_AT_high_pc [DW_FORM_addr] (0x000000000000028e) DW_AT_frame_base [DW_FORM_block1] (<0x01> 55 ) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000447] = "Khandle_missed_dispatchVKgI") DW_AT_decl_file [DW_FORM_data1] ("/Users/bruce/Development/dylan/missing-debug-location/new-dispatch.c") DW_AT_decl_line [DW_FORM_data1] (105) DW_AT_prototyped [DW_FORM_flag] (0x01) DW_AT_type [DW_FORM_ref4] (cu + 0x0127 => {0x00000127}) DW_AT_external [DW_FORM_flag] (0x01) DW_AT_APPLE_optimized [DW_FORM_flag] (0x01) 0x0000060c: DW_TAG_formal_parameter [24] DW_AT_location [DW_FORM_data4] (0x00000000) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000480] = "d_") DW_AT_decl_file [DW_FORM_data1] ("/Users/bruce/Development/dylan/missing-debug-location/new-dispatch.c") DW_AT_decl_line [DW_FORM_data1] (105) DW_AT_type [DW_FORM_ref4] (cu + 0x0127 => {0x00000127}) 0x0000061b: DW_TAG_formal_parameter [24] DW_AT_location [DW_FORM_data4] (0x000000fc) DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000046f] = "parent_") DW_AT_decl_file [DW_FORM_data1] ("/Users/bruce/Development/dylan/missing-debug-location/new-dispatch.c") DW_AT_decl_line [DW_FORM_data1] (105) DW_AT_type [DW_FORM_ref4] (cu + 0x0127 => {0x00000127}) 0x0000062a: DW_TAG_formal_parameter [25] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000047a] = "args_") DW_AT_decl_file [DW_FORM_data1] ("/Users/bruce/Development/dylan/missing-debug-location/new-dispatch.c") DW_AT_decl_line [DW_FORM_data1] (105) DW_AT_type [DW_FORM_ref4] (cu + 0x0127 => {0x00000127}) When I use llvm-dwarfdump, I get a bunch of error messages (and more on 3.6 than on 3.5). I don't get any messages when using the system dwarfdump. I believe that gcc is generating correct debug info for this code.
Created attachment 14039 [details] llvm-dwarfdump output
Created attachment 14040 [details] llvm-dwarfdump output from a 64 bit build It is perhaps interesting to note that compiling with '-arch x86_64' results in the debug info not being missing.
A further simplified (as much as possible, really) test case would be helpful. But in general, optimized debug info in LLVM is still pretty hit-or-miss at best. Specific test cases/deficiencies are still good to know about, though.
Created attachment 14046 [details] Example C code that demonstrates the issue Much more minimized code that reproduces this issue.
Created attachment 14047 [details] llvm-dwarfdump output
Created attachment 14048 [details] llvm-dwarfdump output from a 64 bit build
I don't think I can reproduce this with ToT clang on Linux: $ clang -target i386 -g -O -c -o bad-debug-info.o bad-debug-info.c && llvm-dwarfdump-tot -debug-dump=info bad-debug-info.o | grep -B 2 args_ 0x00000065: DW_TAG_formal_parameter [5] DW_AT_location [DW_FORM_sec_offset] (0x00000000) DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000007d] = "args_") So perhaps this is fixed, or only reproduces on Apple? Not sure.
This was fixed somewhere between r209773 and r211143, which is around June last year. FYI it also works with the version of clang that is in the latest Xcode 6.3 beta.
(works on trunk, fixed some time ago)
I still see this on a recent build: batavia:missing-debug-location bruce $ ~/Development/build-llvm/bin/clang -### -W -Wall -arch i386 -g -O -c -o bad-debug-info.o bad-debug-info.c clang version 3.7.0 (trunk 231926) (llvm/trunk 231925) Target: i386-apple-darwin14.1.0 Thread model: posix "/Users/bruce/Development/build-llvm/bin/clang-3.7" "-cc1" "-triple" "i386-apple-macosx10.10.0" "-emit-obj" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "bad-debug-info.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-target-cpu" "yonah" "-target-linker-version" "241.9" "-gdwarf-2" "-dwarf-column-info" "-coverage-file" "/Users/bruce/Development/dylan/missing-debug-location/bad-debug-info.o" "-resource-dir" "/Users/bruce/Development/build-llvm/bin/../lib/clang/3.7.0" "-O2" "-W" "-Wall" "-fdebug-compilation-dir" "/Users/bruce/Development/dylan/missing-debug-location" "-ferror-limit" "19" "-fmessage-length" "204" "-stack-protector" "1" "-mstackrealign" "-fblocks" "-fobjc-runtime=macosx-fragile-10.10.0" "-fobjc-subscripting-legacy-runtime" "-fencode-extended-block-signature" "-fmax-type-align=16" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" "-vectorize-slp" "-o" "bad-debug-info.o" "-x" "c" "bad-debug-info.c"
(In reply to comment #10) > I still see this on a recent build: > > batavia:missing-debug-location bruce $ ~/Development/build-llvm/bin/clang > -### -W -Wall -arch i386 -g -O -c -o bad-debug-info.o bad-debug-info.c > clang version 3.7.0 (trunk 231926) (llvm/trunk 231925) > Target: i386-apple-darwin14.1.0 > Thread model: posix > "/Users/bruce/Development/build-llvm/bin/clang-3.7" "-cc1" "-triple" > "i386-apple-macosx10.10.0" "-emit-obj" "-disable-free" > "-disable-llvm-verifier" "-main-file-name" "bad-debug-info.c" > "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" > "-mdisable-fp-elim" "-masm-verbose" "-target-cpu" "yonah" > "-target-linker-version" "241.9" "-gdwarf-2" "-dwarf-column-info" > "-coverage-file" > "/Users/bruce/Development/dylan/missing-debug-location/bad-debug-info.o" > "-resource-dir" "/Users/bruce/Development/build-llvm/bin/../lib/clang/3.7.0" > "-O2" "-W" "-Wall" "-fdebug-compilation-dir" > "/Users/bruce/Development/dylan/missing-debug-location" "-ferror-limit" "19" > "-fmessage-length" "204" "-stack-protector" "1" "-mstackrealign" "-fblocks" > "-fobjc-runtime=macosx-fragile-10.10.0" "-fobjc-subscripting-legacy-runtime" > "-fencode-extended-block-signature" "-fmax-type-align=16" > "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" > "-vectorize-slp" "-o" "bad-debug-info.o" "-x" "c" "bad-debug-info.c" Seems something in particular to do with -mrelocation-model pic, doesn't reproduce with -mrelocation-model static.
Under the theory that perhaps this is register-pressure induced due to PIC and x86, I wondered if my original test case would reproduce this issue since it has a lot more variables. Unfortunately, compiling it with -fno-PIC results in a working DW_AT_location: 0x0000062a: DW_TAG_formal_parameter [24] DW_AT_location [DW_FORM_data4] (0x00000000) DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000049b] = "args_") DW_AT_decl_file [DW_FORM_data1] ("/Users/bruce/Development/dylan/missing-debug-location/new-dispatch.c") DW_AT_decl_line [DW_FORM_data1] (105) DW_AT_type [DW_FORM_ref4] (cu + 0x0127 => {0x00000127}) Does that make it any clearer for anyone why this is happening in PIC mode?
Any further thoughts on this since it happens with PIC codegen?
echristo suggest pinging on this bug again. Any ideas?