"File contains no DWARF information..." on Mac

[Anton Sviridov]

First of all, let me tell you I'm very excited to try this tool as I'm working on adding DWARF metadata to a compiler :)

It's very possible I'm doing something wrong here, please let me know.

OS: MacOS
Arch: arm64 (M1)
Version: 2.30
Python: 3.10.9

I get this on both the binary and the bundle

I thought it was an issue with my work, but I get the same when compiling this C file:

#include "stdio.h"
void hello(int i) {
  printf("%d", i);
}

int main() {
  hello(25);
  return 0;
}

$ clang -g test.c -o test.out

Then to confirm I ran dwarfdump on it:

> dwarfdump test.out
test.out:       file format Mach-O arm64

.debug_info contents:

and if I feed the result dSYM bundle to llvm-dwarfdump:

> ~/projects/llvm-project/build/bin/llvm-dwarfdump test.out.dSYM/
test.out.dSYM/Contents/Resources/DWARF/test.out:	file format Mach-O arm64

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000073, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000077)

0x0000000b: DW_TAG_compile_unit
              DW_AT_producer	("Apple clang version 14.0.0 (clang-1400.0.29.202)")
              DW_AT_language	(DW_LANG_C99)
              DW_AT_name	("test.c")
              DW_AT_LLVM_sysroot	("/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk")
              DW_AT_APPLE_sdk	("MacOSX.sdk")
              DW_AT_stmt_list	(0x00000000)
              DW_AT_comp_dir	("<...>/projects/scala-native")
              DW_AT_low_pc	(0x0000000100003f40)
              DW_AT_high_pc	(0x0000000100003fa8)

0x00000032:   DW_TAG_subprogram
                DW_AT_low_pc	(0x0000000100003f40)
                DW_AT_high_pc	(0x0000000100003f78)
                DW_AT_frame_base	(DW_OP_reg29 W29)
                DW_AT_name	("hello")
                DW_AT_decl_file	("<...>/projects/scala-native/test.c")
                DW_AT_decl_line	(2)
                DW_AT_prototyped	(true)
                DW_AT_external	(true)

0x00000047:     DW_TAG_formal_parameter
                  DW_AT_location	(DW_OP_fbreg -4)
                  DW_AT_name	("i")
                  DW_AT_decl_file	("<...>/projects/scala-native/test.c")
                  DW_AT_decl_line	(2)
                  DW_AT_type	(0x0000006f "int")

0x00000055:     NULL

0x00000056:   DW_TAG_subprogram
                DW_AT_low_pc	(0x0000000100003f78)
                DW_AT_high_pc	(0x0000000100003fa8)
                DW_AT_frame_base	(DW_OP_reg29 W29)
                DW_AT_name	("main")
                DW_AT_decl_file	("<...>/projects/scala-native/test.c")
                DW_AT_decl_line	(6)
                DW_AT_type	(0x0000006f "int")
                DW_AT_external	(true)

0x0000006f:   DW_TAG_base_type
                DW_AT_name	("int")
                DW_AT_encoding	(DW_ATE_signed)
                DW_AT_byte_size	(0x04)

0x00000076:   NULL

test.zip

[Seva Alekseyev (he/him)]

Can you please attach a copy of test.out? In a ZIP archive, to keep Github happy.

[Anton Sviridov]

Of course - attached to the original message

[Seva Alekseyev (he/him)]

May I see the dSYM bundle, too? I was afraid something was wrong with my Mach-O parsing, but test.out parses. It just doesn't have the debug info.

[Anton Sviridov]

Here it is:

test.dSYM.zip

If you have any suggestion as to

• How to produce the binary with debug info using clang (I thought -g was enough)
• Any binary on a normal MacOS installation that might have the debug info - so I can test it

[Seva Alekseyev (he/him)]

That dSYM bundle fails to open in DWARF Explorer because of the naming convention I was assuming for Mac build tools - that the executable has no extension (or, equivalently, no dot characters in name), the bundle is called "appname.app.dSYM", and the debug symbols are inside an executable-formatted file called appname under Contents/Resources/DWARF in the bundle.

Notably, if you look inside that bundle and open Contents/Resources/DWARF/test.out in DWARF Explorer, it opens and parses in DWARF Explorer just fine.

It's hard to tell, when it comes to build tools, what is standard that one must adhere to, and what is mere tool convention. No one prevents your compiler from emitting files with an extension. I can fix DWARF Explorer to take files such as yours - even though it might drag in some false positives. EDIT: done that.

That said, as far as I know, the .out thing has roots deep in the ancient Unix history, a.out was an early, pre-ELF executable file format, and even Unix systems have abandoned it many years ago in favor of extensionless executables. I know a.out is still the default output file name in compilers, but if you use Xcode, you'll never know about it.

[Seva Alekseyev (he/him)]

Is this still an issue? Have you tried it with your homegrown compiler?

[Anton Sviridov]

He @sevaa!

I've upgraded to 2.31 and it seems like lots of things are fixed - both with Clang-produced binary, and with Scala Native one 🎉

Thanks a lot, what an excellent tool!