[PATCH] D84565: [Darwin] [Driver] Clang should invoke dsymutil for lto builds -g*

Daniel Sanders via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jul 24 18:57:15 PDT 2020


dsanders added inline comments.


================
Comment at: clang/lib/Driver/Driver.cpp:2037
+    bool isGeneratingTemporaryObject =
+        ContainsCompileOrAssembleAction(Actions.back()) || LTOMode != LTOK_None;
     if ((enablesDebugInfo || willEmitRemarks(Args)) &&
----------------
beanz wrote:
> dsanders wrote:
> > This should fix the same issue as the workaround I was using in D84127.
> > 
> > I'm not entirely convinced that this is all of it though. It seems strange to me that these two scripts produce different build products (aside from ret0.o):
> > ```
> > $ rm -rf external ret0 ret0.*
> > $ echo 'int main() { return 0; }' > ret0.c
> > $ use_cflags="--sysroot=$SYSROOT -g"
> > $ ../build/bin/clang -o ret0 ret0.c ${=use_cflags}
> > $ ls
> > ret0      ret0.c    ret0.dSYM
> > ```
> > ```
> > $ rm -rf external ret0 ret0.*
> > $ echo 'int main() { return 0; }' > ret0.c
> > $ use_cflags="--sysroot=$SYSROOT -g"
> > $ ../build/bin/clang -c -o ret0.o ret0.c ${=use_cflags}
> > $ ../build/bin/clang -o ret0 ret0.o ${=use_cflags}
> > $ ls
> > ret0   ret0.c ret0.o
> > ```
> > I'd expect them to either consistently extract the dSYM or consistently lipo the slices together including the debug info. I don't have a strong opinion about which is right, it's just the inconsistency that's bothering me
> The reason they behave differently is because in the case where clang compiles + links in the same invocation the intermediate object files are deleted. In MachO we do not link debug information in ld, instead we do it in dsymutil. dsymutil cannot run across a temporary object file that has been deleted, so the clang driver runs it for you.
> 
> Clang doesn't run it in the case of just linking object files because it takes time and isn't strictly required as long as you keep all your object files around so that your debugger can find the unlinked debug info in the object files. This is why one of the common ways people speed up debug builds with mach-o is to skip dSYM generation.
That makes sense. Although when you do want dSYM's, it does end up requiring the build system to know the logic clang is using and either move the one clang emitted or invoke dsymutil to make one depending on what clang did. 

At the moment, the options that cause dsymutil to be invoked by clang that I know of are -flto, compiling/assembling, and multiple values for -arch. It would be easier on the build system if it could force them to be emitted and control where they end up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84565





More information about the cfe-commits mailing list