[PATCH] D94647: [Driver] -gsplit-dwarf: Produce .dwo regardless of -gN for -fthinlto-index=

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.


================
Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3758
+  // Normally -gsplit-dwarf is only useful with -gN. For -gsplit-dwarf in the
+  // backend phase of a distributed ThinLTO which does object file generation
+  // and no IR generation, -gN should not be needed. So allow -gsplit-dwarf with
----------------
inglorion wrote:
> tejohnson wrote:
> > MaskRay wrote:
> > > dblaikie wrote:
> > > > tejohnson wrote:
> > > > > Better to simply check if the input type is IR/BC via types::isLLVMIR(Input.getType()). Technically you don't need ThinLTO to do a clang compile with bitcode input. Looks like Input can be passed down from the caller.
> > > > Good point! +1 to that.
> > > That currently does not work:
> > > `clang -g -c -flto a.c; fclang -gsplit-dwarf -g a.o -o a`
> > > there is no .dwo
> > I assume you mean clang and not "fclang"?
> > 
> > Try with "-x ir" like "clang -gsplit-dwarf -g -x ir a.o -o a". I thought that the -x ir was needed when passing a .o file that was actually bitcode?
> > I thought that the -x ir was needed when passing a .o file that was actually bitcode?
> 
> I think that's a linker invocation, not a codegen invocation.
> 
> I would have spelled it
> 
>   clang -fuse-ld=lld -flto -gsplit-dwarf -g a.o -o a
> 
> And, for me at least, it does use debug fission:
> 
>   objdump -g a | grep dwo                                    
>       DW_AT_GNU_dwo_name DW_FORM_strp
>       DW_AT_GNU_dwo_id   DW_FORM_data8
>       <14>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x29): a_dwo/0.dwo
>       <18>   DW_AT_GNU_dwo_id  : 0x24fab96c73f98143
>     0x00000020 2f746d70 2f747374 00615f64 776f2f30 /tmp/tst.a_dwo/0
>     0x00000030 2e64776f 00                         .dwo.
> 
They're somewhat different things.
```
clang -gsplit-dwarf -g -x ir a.o -o a
```
With a single file, this is the same as the lto invocation - but with multiple files this is different, because it compiles the IR to object code, then links, rather than linking then compiling to object code.
The easier way to write "Compile to object code" includes things like:
```
clang -c -gsplit-dwarf a.bc
clang -c -gsplit-dwarf a.ll
```
for bitcode IR and textual IR respectively. 

But yes, all these forms, whatever user-driven invocation causes IR->object code generation to occur, should accept and respect -gsplit-dwarf. And I think hopefully that's the case after/with D94655


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94647/new/

https://reviews.llvm.org/D94647