smeenai 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: > 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) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122258/new/ https://reviews.llvm.org/D122258 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
