# Understanding Apple Debug Info

DevFeed: [Understanding Apple Debug Info](<https://devfeed.tech/articles/understanding-apple-debug-info-25412.md>)

Original publisher: [Read original article](<https://smileykeith.com/2025/09/21/understanding-apple-debug-info/>)

Author: Keith Smiley

Published: 2025-09-21T17:00:00Z

Content type: tutorial

Language: en

Sources: [Keith Smiley](<https://devfeed.tech/sources/keith-smiley.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [Xcode](<https://devfeed.tech/topics/xcode.md>), [C](<https://devfeed.tech/topics/c.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [apple](<https://devfeed.tech/tags/apple.md>), [binaries](<https://devfeed.tech/tags/binaries.md>), [build](<https://devfeed.tech/tags/build.md>), [c](<https://devfeed.tech/tags/c.md>), [clang](<https://devfeed.tech/tags/clang.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [debug](<https://devfeed.tech/tags/debug.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [ios](<https://devfeed.tech/tags/ios.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [macos](<https://devfeed.tech/tags/macos.md>), [xcode](<https://devfeed.tech/tags/xcode.md>)

## AI overview

This article explains how debug information works for Apple platforms and Mach-O binaries, contrasting the approach with Linux ELF binaries. It shows how compiler-generated debug metadata is stored in intermediate object files and located by lldb, then introduces issues that can arise in complex or distributed Bazel builds, including invalid absolute paths.

## Source excerpt

Apple platforms (macOS, iOS, etc), and specifically Mach-O binaries, have a slightly different approach to debug info than ELF binaries for Linux. If you are familiar with Xcode, you might have seen a few related settings that control what is produced and wondered what the trade-offs are. The goal of this post is to help you debug cases where these differences lead to a degraded debugging experience in lldb so that you can fix them. If you have a particularly complex build, potentially managed by Bazel1 or another tool, especially if you are using distributed builds, you are even more likely to hit issues. Let's dive in to how the pieces fit together. A brief explanation of debug info Debug info is metadata produced by the compiler that is consumed by debuggers (like lldb), profilers, and other tools. It is used to map runtime information, like addresses, function arguments, and stack traces, back to the source that was used to produce the binary. Without this information debugging in lldb shows primarily raw instructions and addresses, which is rarely acceptable for common debugging workflows. Inspecting debug info When building for Apple platforms debug info isn't contained in the final binary (this is the primary difference from the default Linux workflows). Instead the binary contains references to the files where lldb can find it (this is conceptually similar to if you use -gsplit-dwarf on Linux). Let's inspect some binaries to see what this really means. First we create a small binary: $ cat main.c int main() { return 0; } $ clang main.c -g -c -o main.o $ clang main.o -o main If we attempt to inspect the debug info contained in main, we find nothing: $ dwarfdump main # use llvm-dwarfdump if not on macOS main: file format Mach-O arm64 .debug_info contents: However when we debug this binary in lldb, you will correctly see the source file and line number information: $ lldb -- main (lldb) target create "main" Current executable set to '/tmp/demo/main' (arm64). (l