On Mon, Nov 24, 2014 at 4:26 PM, Eric Christopher <echri...@gmail.com> wrote:
> > > On Mon Nov 24 2014 at 11:20:11 AM Adrian Prantl <apra...@apple.com> wrote: > >> >> > On Nov 24, 2014, at 9:22 AM, David Blaikie <dblai...@gmail.com> wrote: >> >> >> >> The debug info in foo.o will look like this:: >> >> >> >> .debug_info.dwo >> > >> > (so if this goes in debug_info.dwo then it would be in foo.dwo, not >> foo.o... but I had some further thoughts about this... ) >> > >> > So - imagining a future in which modules are real object files that get >> linked into the final executable because they contain things like >> definitions of linkonce_odr functions (so that any object file that has all >> the linkonce_odr calls inlined doesn't have to carry around a (probably >> duplicate) definition of the function) - then that object file could also >> contain the skeleton CU unit (& associated line table, string table, etc) >> for not only these functions, but for all the types, etc, as well. >> > >> > In that world, we would have exactly fission, nothing new (no two-level >> fission, where some static-data-only skeletons appear in the .dwo file and >> the skeletons with non-static data (ie: with relocations, such as those >> describing concrete function definitions or global variables) appear in the >> .o file). >> > >> > We can reach that same output today by adding these skeletons into the >> .o file (in debug_info, not debug_info.dwo) and using comdat to unique them >> during linking. >> >> Just to be sure, could you clarify what exactly would go into these >> skeletons? I’m a little worried that this may increase the size of the .o >> files quite a bit and thus eat into our performance gains. >> > > FWIW skeletons are very small and completely dwarfed (get it?) by the size > of the line table or anything else. > Yeah, just reserving some judgment until actual numbers/providing an 'out' if necessary/hedging bets/etc - it was worth removing type unit skeletons (which, between debug_types and .rela.debug_types made up about 30% of debug info in .o files) & module skeletons would probably be one or two orders of magnitude smaller (10-100 public types per module?) that's something like 4% (for 1:10) or less, probably much less. > > -eric > > >> > >> > This option would be somewhat wasteful for now (& in the future for any >> module that had /no/ concrete code that could be kept in the module - such >> as would be the case in pure template libraries with no explicit >> instantiation decl/defs, etc) because it would put module references in the >> .o, but it would mean not having to teach tools new fission tricks >> immediately. >> >> At least as far as LLDB is concerned, it currently doesn’t support >> fission at all, so we will have to start fresh there anyway. >> >> > >> > Then, if we wanted to add an optimization of double-indirection fission >> (having skeleton CUs in .dwo files that reference further .dwo files) we >> could do that as a separate step on top. >> > >> > It's just a thought - Maybe it's an unnecessary extra step and we >> should just go for the double-indirection from the get-go, I'm not sure? >> >> Given our plans for a more efficient “bag of dwarf”+index format, which >> will need work on the consumer side anyway, I’m leaning more towards the >> latter, but I can see the attractiveness of having a format that works with >> existing dwarf consumers out-of-the-box. It looks like that the pure >> fission format would make a better default for platforms that use, e.g., >> gdb as their default debugger. >> >> -- adrian >> > >> > Opinions? >> > >> >>
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
