public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Molenda <jmolenda@apple.com>
To: Cary Coutant <ccoutant@google.com>
Cc: dwarf-discuss@lists.dwarfstd.org, gcc@gcc.gnu.org,
	gdb@sourceware.org, Doug Evans <dje@google.com>,
	Paul Pluzhnikov <ppluzhnikov@google.com>,
	Sterling Augustine <saugustine@google.com>
Subject: Re: RFC: DWARF Extensions for Separate Debug Info Files ("Fission")
Date: Fri, 23 Sep 2011 01:35:00 -0000	[thread overview]
Message-ID: <B6D4E49C-77EC-4BE7-8EAA-8897A4682F9F@apple.com> (raw)
In-Reply-To: <CAHACq4o43uGDEEKQRiYgnWWXSnDzRD1Z_-4z2HQ=bSaTpgyrjQ@mail.gmail.com>

Hi Cary, just one quick clarification -

On Sep 22, 2011, at 5:21 PM, Cary Coutant wrote:

> Previous Implementations of Separate Debug Information
> ======================================================
> 
> In the Sun and HP implementations, the debug information in the
> relocatable objects still requires relocation at debug time, and
> the debugger must read the summary information from the
> executable file in order to map symbols and sections to the
> output file when processing and applying the relocations. The
> Apple implementation avoids this cost at debug time, but at the
> cost of having a separate link step for the debug information.


The Apple approach has both the features of the Sun/HP implementation as well as the ability to create a standalone debug info file. 

The compiler puts DWARF in the .o file, the linker adds some records in the executable which help us to understand where files/function/symbols landed in the final executable[1].  If the user runs our gdb or lldb on one of these binaries, the debugger will read the DWARF directly out of the .o files on the fly.  Because the linker doesn't need to copy around/update/modify the DWARF, link times are very fast.  If the developer decides to debug the program, no extra steps are required - the debugger can be started up & used with the debug info still in the .o files.

Clearly this is only viable if you have the .o files on your computer so we added a command, "dsymutil", which links the DWARF from the .o files into a single standalone ".dSYM" file.  The executable file and the dSYM file have a shared 128-bit number to ensure that the debug info and the executable match; the debugger will ignore a dSYM with a non-matching UUID for a given executable.  A developer will typically create a dSYM when they sending a copy of the binary to someone and want to provide debug information, or they are archiving a released binary, or they want to debug it on another machine (where the .o files will not be in place.)

In practice people create dSYMs rarely -- when they are doing iterative development on their computer, all of the DWARF sits in the .o files unprocessed unless they launch a debugger, link times are fast.


As a minor detail, the dSYM is just another executable binary image on our system (Mach-O file format), sans any of the text or data of the real binary file, with only the debug_info, etc. sections.  The name "dSYM" was a little joke based on the CodeWarrior "xSYM" debug info format.

J

  reply	other threads:[~2011-09-23  1:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-23  0:22 Cary Coutant
2011-09-23  1:35 ` Jason Molenda [this message]
2011-09-23  2:21   ` Paul Pluzhnikov
2011-09-23 17:58   ` Cary Coutant
2011-09-23 21:02     ` Jason Molenda
2011-09-23 21:35       ` [Dwarf-Discuss] " John DelSignore
2011-09-23 13:51 ` Jan Kratochvil
2011-09-23 17:50   ` Cary Coutant
2011-10-20 17:56 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B6D4E49C-77EC-4BE7-8EAA-8897A4682F9F@apple.com \
    --to=jmolenda@apple.com \
    --cc=ccoutant@google.com \
    --cc=dje@google.com \
    --cc=dwarf-discuss@lists.dwarfstd.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=ppluzhnikov@google.com \
    --cc=saugustine@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).