[PATCH] D122258: [MC] Omit DWARF unwind info if compact unwind is present where eligible

[Jez Ng via Phabricator via cfe-commits]

int3 added inline comments.


================
Comment at: clang/lib/CodeGen/BackendUtil.cpp:456
   Options.MCOptions.SplitDwarfFile = CodeGenOpts.SplitDwarfFile;
+  Options.MCOptions.EmitDwarfUnwind = CodeGenOpts.getEmitDwarfUnwind();
   Options.MCOptions.MCRelaxAll = CodeGenOpts.RelaxAll;
----------------
smeenai wrote:
> smeenai wrote:
> > int3 wrote:
> > > smeenai wrote:
> > > > int3 wrote:
> > > > > this code doesn't execute if clang is passed an assembly file instead of a .c file, so this option doesn't have the desired effect on assembly inputs. I'm not sure what's the right way to tackle this, or if this behavior inconsistency is acceptable
> > > > > 
> > > > > 
> > > > It seems unfortunate to have that inconsistency. From what I can tell, clang/tools/driver/cc1as_main.cpp looks like it might be the rough equivalent of this for the integrated assembler?
> > > that's what I'd thought too, but I set a breakpoint on `cc1as_main` & `ExecuteAssemblerImpl` and then ran `clang -c foo.s`; neither breakpoint triggered
> > Hmm, interesting. If you run with `-###`, is `-cc1as` being invoked in-process or out of process? Idk if the in-process cc1as has a different entry point.
> Nah, looks like in-process cc1as should be calling `cc1as_main` as well: https://github.com/llvm/llvm-project/blob/98616cfc02613d98964588fac6494ec7583c495f/clang/tools/driver/driver.cpp#L319
> 
> (If it's out of process you'd need to debug the cc1as process and not the driver process, of course, but I'd be surprised if you end up with an out of process cc1as)
ah yeah I guess that's it. I'd enabled `settings set target.process.follow-fork-mode child` but that doesn't seem to have the desired effect; but modifying cc1as_main itself shows that it is indeed being called.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122258