dsanders added a comment.

In D84565#2173615 <https://reviews.llvm.org/D84565#2173615>, @JDevlieghere 
wrote:

> When you don’t pass any specific options to the linker, it’s going to 
> generate a temporary `lto.o` file in `/tmp` and delete it after the link. 
> When `dsymutil` will try to read that, it won't be there anymore. Unless I'm 
> missing I don't think this is going to work. If it turns out I'm mistaken 
> please add that situation as a test case.


Are you thinking of the `-Wl,-object_path_lto,path/foo-lto.o` code in 
AddLLVM.cmake where dsymutil is invoked after clang finishes? I'm using the 
same code path as this patch in https://reviews.llvm.org/D84127 using an empty 
source file to force ContainsCompileOrAssembleAction() to be true and get 
dsymutil to be invoked. When clang manages both the per-arch links and the 
dsymutil, the temporary objects get unique names (e.g. `-object_path_lto 
/var/folders/0s/8zdwsz0d1glcx6v1nc_nv5gw0000gn/T/cc-95f3fc.o`) and stick around 
until after dsymutil is invoked.



================
Comment at: clang/lib/Driver/Driver.cpp:2037
+    bool isGeneratingTemporaryObject =
+        ContainsCompileOrAssembleAction(Actions.back()) || LTOMode != 
LTOK_None;
     if ((enablesDebugInfo || willEmitRemarks(Args)) &&
----------------
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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84565



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

Reply via email to