aaronpuchert added inline comments.

================
Comment at: lib/CodeGen/BackendUtil.cpp:1345
   Conf.RemarksPasses = CGOpts.OptRecordPasses;
-  Conf.DwoPath = CGOpts.SplitDwarfFile;
+  Conf.DwoPath = CGOpts.SplitDwarfOutput;
   switch (Action) {
----------------
tejohnson wrote:
> aaronpuchert wrote:
> > tejohnson wrote:
> > > aaronpuchert wrote:
> > > > aaronpuchert wrote:
> > > > > @pcc Your documentation for `DwoPath` suggests that this should be 
> > > > > the actual output filename. However, the test that you added together 
> > > > > with this line in rC333677 doesn't fail whatever garbage I write into 
> > > > > that field here. What can I add to that so that it fails when we 
> > > > > don't do the right thing here?
> > > > @pcc Could you (or perhaps @tejohnson) comment on what the intended 
> > > > behavior is here, and how I can change the test so that it fails when I 
> > > > do the wrong thing? Is this the name of the file we write the split 
> > > > debug info to, or is it the value we use for the DW_AT_[GNU_]dwo_name 
> > > > attribute in the skeleton CU?
> > > It is the name of the file the split debug info is written to. If you 
> > > test by changing the file name given to the -split-dwarf-file option in 
> > > test/CodeGen/thinlto-split-dwarf.c, make sure you clean up the old one in 
> > > your test output directory. When I tested it just now, it initially still 
> > > passed because I had an old one sitting in the output directory from a 
> > > prior run. Once I removed that it failed with the new name (without 
> > > changing the corresponding llvm-readobj invocation).
> > Thanks, I didn't consider that. I wasn't even aware that test output is 
> > persisted.
> > 
> > It seems `DwoPath` is used both as output filename and as value for 
> > `DW_AT_[GNU_]dwo_name` in the skeleton CU. `llc` has separate options for 
> > both: `-split-dwarf-file` for the attribute and `-split-dwarf-output` for 
> > the output filename. I want to do the same for Clang. Then we should 
> > probably separate them for LTO, too.
> > 
> > What is the use case for `-split-dwarf-file` with an individual thin 
> > backend? Is that used for distributed/remote builds? Also is there any 
> > non-cc1 way to use it? There is `--plugin-opt=dwo_dir=...` for the LTO 
> > linker plugin, but that seems to go a different route.
> This is the path taken for distributed ThinLTO, the plugin-opt passed to 
> linker are for in-process ThinLTO. While -split-dwarf-file is a cc1 option, 
> it is normally set automatically from the filename under -gsplit-dwarf (see 
> where it is set in Clang::ConstructJob).
Ok, then it makes sense to do the changes for LTO as well.

You're right that `-split-dwarf-file` is produced for `-gsplit-dwarf`, but not 
with LTO, right? When I set `-gsplit-dwarf` on a vanilla ThinLTO build, then 
the flag is just ignored and I'm getting the debug info in the final 
executables/shared objects. (At least with Clang 8.)

I'm asking because this changes the cc1-interface, and while I have adapted 
`Clang::ConstructJob`, I'm not sure how distributed ThinLTO works, and whether 
there have to be changes.

If it works like test/CodeGen/thinlto-split-dwarf.c, using cc1-options, then 
users might have to adapt after this change.


Repository:
  rC Clang

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

https://reviews.llvm.org/D59673



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to