[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

Wed Aug 24 03:18:32 PDT 2022

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