Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-10-20 Thread Tom Tromey
Cary == Cary Coutant ccout...@google.com writes: Cary At Google, we've found that the cost of linking applications with Cary debug info is much too high. [...] Cary * .debug_macinfo - Macro information, unaffected by this design. There is also the new .debug_macro section. This section refers

Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-23 Thread Jan Kratochvil
On Fri, 23 Sep 2011 02:21:44 +0200, Cary Coutant wrote: * .debug_pubtypes - Public types for use in building the .gdb_index section at link time. This section will have an extended format to allow it to represent both types in the .debug_dwo_info section and type units in .debug_types.

Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-23 Thread Cary Coutant
* .debug_pubtypes - Public types for use in building the   .gdb_index section at link time. This section will have an   extended format to allow it to represent both types in the   .debug_dwo_info section and type units in .debug_types.    ^^^    = .dwo_info , maybe both

Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-23 Thread Cary Coutant
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.

Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-23 Thread Jason Molenda
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

Re: [Dwarf-Discuss] RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-23 Thread John DelSignore
Hi Jason, Jason Molenda wrote: 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

RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-22 Thread Cary Coutant
At Google, we've found that the cost of linking applications with debug info is much too high. A large C++ application that might be, say, 200MB without debug info, is somewhere around 1GB with debug info, and the total size of the object files that we send to the linker is around 5GB (and that's

Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-22 Thread Jason Molenda
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

Re: RFC: DWARF Extensions for Separate Debug Info Files (Fission)

2011-09-22 Thread Paul Pluzhnikov
On Thu, Sep 22, 2011 at 6:35 PM, Jason Molenda jmole...@apple.com wrote: Because the linker doesn't need to copy around/update/modify the DWARF, link times are very fast. AFAIU, the link times are fast only if all the files are local to the developers' machine. They will not be fast (and the