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