This is the mail archive of the
mailing list for the GDB project.
Re: RFC: DWARF Extensions for Separate Debug Info Files ("Fission")
- From: Cary Coutant <ccoutant at google dot com>
- To: Jason Molenda <jmolenda at apple dot com>
- Cc: dwarf-discuss at lists dot dwarfstd dot org, gcc at gcc dot gnu dot org, gdb at sourceware dot org, Doug Evans <dje at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Sterling Augustine <saugustine at google dot com>
- Date: Fri, 23 Sep 2011 10:58:34 -0700
- Subject: Re: RFC: DWARF Extensions for Separate Debug Info Files ("Fission")
- References: <CAHACq4o43uGDEEKQRiYgnWWXSnDzRD1Z_-4z2HQ=bSaTpgyrjQ@mail.gmail.com> <B6D4E49C-77EC-4BE7-8EAA-8897A4682F9F@apple.com>
> The Apple approach has both the features of the Sun/HP implementation as well as the ability to create a standalone debug info file.
Thanks for the clarifications. I based my comments on a description
you sent me a couple of years ago, and I apologize for any
oversimplifications I introduced.
> 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.
Did you intend to add a footnote?
> ?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.
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