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. -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
