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 21:02:00 -0000 [thread overview]
Message-ID: <E4D200C3-534F-4562-9813-E765975E8692@apple.com> (raw)
In-Reply-To: <CAHACq4p5-EscmeTZ0giD+F2M0T7=S77FTpq8=a-4aoOVc9FX_A@mail.gmail.com>
On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote:
>> 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].
>
> Did you intend to add a footnote?
Yeah, I realized after I sent the email - it didn't seem interesting enough to warrant a separate followup.
The records that our linker puts in the executable are in the form of stabs entries. There are a handful of stabs records created - file start, file end, function start, function end, symbol, pointer to a .o file, maybe one or two others. We chose that format because it was trivial to support and we already had tools for stripping these records out of the executable once the dSYM had been created.
Once a dSYM has been created with all of the DWARF collected in a single file, our DWARF is parseable by any debug info consumer with minimal changes -- they need to know to look in a separate file for the DWARF from the main executable, but the format itself is unchanged. Supporting the debug-information-in-.o-files is more involved, I don't know if any of the third-party debuggers on our platform work with it.
> We're trying to achieve something very similar, but we have the
> additional goal of separating the info from the .o files because of
> our distributed build environment. I also wanted to attempt to
> standardize the approach, instead of having each vendor go in separate
> directions.
Yeah, if your regular build environment involves distributed compilation, and the .o files need to be copied to a central system for the linker, then I can see why you're pursuing this approach. For us, the most common usage is single-computer compilation & linking -- where the linker never pages in the debug info sections from the .o files so their size is not particular important.
J
next prev parent reply other threads:[~2011-09-23 21:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-23 0:22 Cary Coutant
2011-09-23 2:36 ` Jason Molenda
2011-09-23 2:26 ` Paul Pluzhnikov
2011-09-23 17:58 ` Cary Coutant
2011-09-23 21:02 ` Jason Molenda [this message]
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 21:43 ` 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=E4D200C3-534F-4562-9813-E765975E8692@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).