[cfe-dev] [PATCH] Wrap clang modules inside Mach-O/ELF/COFF containers

[Richard Smith]

On Fri, Jan 9, 2015 at 4:03 PM, Adrian Prantl <aprantl at apple.com> wrote:

> On Jan 9, 2015, at 3:57 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Tue, Jan 6, 2015 at 10:07 AM, Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> > On Dec 12, 2014, at 8:47 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> >
>> >
>> >> On Dec 12, 2014, at 5:37 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>> wrote:
>> >>
>> >>
>> >>> On Dec 12, 2014, at 4:33 PM, Eric Christopher <echristo at gmail.com>
>> wrote:
>> >>>
>> >>> Debug info for types isn't inherently a code generation concept. If
>> you think about it, debug info for types is a stable (if lossy)
>> serialization method for a module file. The line number etc for when
>> there's code generated is a separate issue.
>> >>
>> >> I see what you mean, but it is a traditionally codegen product with a
>> particular use-case, and it’s not reasonable to force it on every clang
>> client that only wants to parse code, like libclang, static analyzers,
>> migrators, refactoring tools, etc., or builds that didn’t ask for it.
>> >
>> > Good point, I tend to forget about non-compiler users of clang modules.
>> >
>> > If we do decide that having clang modules without debug info is
>> desirable, and we want debug info to be generated lazily (only when needed)
>> then putting it into a separate file is preferable, because it then can be
>> captured as a dependency by build systems.
>> >
>> > It looks like at this point everyone’s argument is really depending on
>> an assumption that emitting debug info is expensive (or really cheap!,
>> respectively), so my suggestion is to revisit this thread once I actually
>> have some numbers on how long it takes to emit debug info and how much
>> space it takes up. I’ll try to get that done soon.
>>
>> Hi Argyrios,
>>
>> back from the break, here are the promised numbers to make our decision
>> easier:
>>
>> I did an experiment where I patched clang to emit debug type info for
>> each type (patch attached for the curious), and compiled an empty program
>> that imports the Cocoa.h header. To compare the sizes I emitted the DWARF
>> to a separate file:
>>
>> -rw-r--r--  1 adrian  staff  2151068 Dec 19 16:30
>> Foundation-3QM1BFEPXW18W.pcm
>> -rw-r--r--  1 adrian  staff   110772 Dec 19 16:30
>> Foundation-3QM1BFEPXW18W.pcm.o
>>
>> here’s AppKit:
>>
>> -rw-r--r--  1 adrian  staff  3302744 Dec 19 16:40 AppKit-5HXLHEH4UB4M.pcm
>> -rw-r--r--  1 adrian  staff   279080 Dec 19 16:40
>> AppKit-5HXLHEH4UB4M.pcm.o
>>
>> The median of the size of the DWARF compared to the size of the pcm over
>> all the modules pulled in by Cocoa.h is 5%; i.e., the DWARF would take up
>> roughly 5% of the size of the individual modules.
>>
>> From these numbers I would argue that DWARF emission is comparatively
>> cheap. To keep the implementation simple, I’d prefer to have everything in
>> one file; this way we won’t have to introduce another layer of locking for
>> creating the pcm.o files lazily, but if someone wants to point out that
>> this is a lame excuse, be my guest ;-)
>> [Another reason to argue for separate .pcm.o files is if we ever want to
>> put something target-specific in there, such as code. Currently this is not
>> the case,
>
>
> I certainly have plans to do this, as mentioned previously on this thread.
>
>
>> and even if we did this, we would still benefit from having the DWARF
>> type information shared between the several .pcm.o files]
>>
>
> Is there any disadvantage to having the debug information for a module
> split over two .o files (one for the types and another for the inline
> functions / template instantiations)?
>
>
> I think that having it split is actually an advantage. By split I mean
> having the .pcm which contains AST and the DWARF for the types ands then
> several .pcm.o’s for each target that contains e.g., IR for inline
> functions+debug info and the debug info in the various targets refers to
> the shared DWARF type info in the .pcm. As far as the debug info is
> concerned, we would use the same mechanisms for the .pcm.o files as we
> would for any other object that imports the module.
>

OK, I'm fine with that (though in our case I think we'll want to turn this
feature off and put all the DWARF output into the same file as the inline
functions etc). Do you have a plan for supporting debug fission with this
mode?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150109/e0c4089d/attachment.html>