labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
In D131437#3741132 <https://reviews.llvm.org/D131437#3741132>, @clayborg wrote: > So I can't get -fsplit-dwarf-inlining to emit anything when I try to cross > with clang. I add the flag but no extra function info gets emitted in the > dwarf in the main executable. I tried: > > clang++ -gdwarf-5 -gsplit-dwarf -fsplit-dwarf-inlining -c main.cpp -o > main2.o You probably also need to enable optimizations for any inlining to happen (maybe not if you use always_inline). And you need to make the source sufficiently nontrivial so that there is some debug info to produce. For example, this code worked for me: $ cat main.cpp int use(int); int inlined(int x) { return 1 + use(x); } int main() { return 2*inlined(57); } $ clang++ -gdwarf-5 -gsplit-dwarf -fsplit-dwarf-inlining -c main.cpp -O1 > I also tried to create an simple a.out program with a DWO_ID of zero. If it > obj2yaml and then to yaml2obj, something gets messed up in the binary, so not > sure if ojb2yaml + yaml2obj can handle fission binaries correctly. I'm not surprised that fails, but possible the problem was not with fission. obj2yaml is not good at round-tripping fully linked binaries (with program headers and stuff). Things work much better for .o files (which should be sufficient for your needs here). I also often find it easier to take the assembly output (`clang -s`) and tweak that, instead of going all the way to object code and then back to yaml. ================ Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h:339 /// Value of DW_AT_GNU_dwo_id (v4) or dwo_id from CU header (v5). - uint64_t m_dwo_id; + llvm::Optional<uint64_t> m_dwo_id; ---------------- clayborg wrote: > labath wrote: > > What's the relationship of this field and the m_is_dwo flag? Do we need > > both? > I think the "m_is_dwo" is set to true if this is a DWO file, where m_dwo_id > is for the skeleton compile unit. So they are different and can't be derived > from each other if I understand the code correctly. ok. makes sense. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131437/new/ https://reviews.llvm.org/D131437 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
