> On Mar 17, 2015, at 10:03 AM, Greg Clayton <[email protected]> wrote: > > >> On Mar 17, 2015, at 9:46 AM, David Blaikie <[email protected]> wrote: >> >> >> >> On Tue, Mar 17, 2015 at 9:42 AM, Greg Clayton <[email protected]> wrote: >> >>> On Mar 16, 2015, at 6:47 PM, David Blaikie <[email protected]> wrote: >>> >>> >>> >>> On Mon, Mar 16, 2015 at 5:14 PM, Adrian Prantl <[email protected]> wrote: >>> >>> Thanks for the explanation David, I missed that it is entirely the linker's >>> (or some dwarf post-processor's) responsibility to find the module files >>> and link in the debug info from the .pcm files, so debugger doesn’t notice >>> a difference. >>> >>> I think there's still some confusion here. Sorry if I'm rehashing >>> something, but I'll try to explain how this all works. >>> >>> Normal split DWARF: >>> >>> Compiler generates two files: .o and .dwo. >>> .dwo has static, non-relocatable debug info. >>> .o has a skeleton compile_unit that has the name of the .dwo file and a >>> hash to verify that the .dwo file isn't stale when the debugger reads it. >>> The .o files are all linked together, the .dwo files stay where they are. >>> The debugger reads the linked executable, finds the skeleton compile_units >>> contained therein, and find/loads the .dwo files >>> >>> The scenario I have in mind for module debug info is this: >>> Module is compiled as an object file with debug info (this file is actually >>> a .dwo file, even if it has some other extension - it has the >>> non-relocatable debug info in it) >>> .o file has a comdat'd skeleton compile_unit describing the .dwo/module file >>> <from here on no extra work is required, the linker and debugger just act >>> as normal> >>> The .o files are linked together, the skeleton compile_units get >>> deduplicated by the linker (comdat sections) >> >> One issue I can think of is we will need to figure out a way to make COMDAT >> work with mach-o. COMDAT requires large number of sections and mach-o can >> only have 255. >> >> Ah, fair enough - how does MachO handle inline functions (the most common >> use of comdat) currently, then? > > Currently mach-o relies on symbols in the symbol table being marked as weak > and I believe the data for these symbols are in special sections that are > marked as containing items that can be coalesced. > That’s not necessarily an issue that needs to be solved on Darwin, or am I maybe missing something? The linker leaves all debug info in the .o (as it currently does) and llvm-dsymutil is resolving all the external module type references while creating the .dSYM bundle.
-- adrian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
