dsymutil emits warnings with experimental lto mode

[rauhul]

When using --experimental-lto-mode=full dsymutil complains about not being able to find (intermediate?) object files created during the LTO process. Example:

$ git clone git@github.com:apple/swift-nio.git
$ cd swift-nio
$ swift build --configuration release --experimental-lto-mode=full --verbose
warning: (arm64) /tmp/lto.o unable to open object file: No such file or directory
warning: (arm64)  could not find object file symbol for symbol _$sSo14_sa_DoubleWordaMa
warning: (arm64)  could not find object file symbol for symbol _$sSo14_sa_DoubleWordaMaTm
...

[kubamracek]

If this is using ld64 on a Mac, then you want this ld flag to retain the lto.o file (otherwise it gets deleted after link):

     -object_path_lto filename
             When performing Link Time Optimization (LTO) and a temporary mach-o object file is needed, if this option is used, the temporary file will be
             stored at the specified path and remain after the link is complete.  Without the option, the linker picks a path and deletes the object file
             before the linker tool completes, thus tools such as the debugger or dsymutil will not be able to access the DWARF debug info in the temporary
             object file.

[rauhul]

@neonichu is there a good way to add arguments generated by ProductBuildDescription.linkArguments conditioned on the actual linker being used?

[neonichu]

Not aware of anything. I haven't paid super close attention to the new linker, but I believe we also have to fall back to ld64 on certain platforms/arches and I am not sure if that's something that's automatic or not, so it's possible that we don't even know which linker is in use.

@owenv maybe you can shed some light on that?

[owenv]

The new and old macOS linkers both support -object_path_lto, I think what @rauhul needs is a way to vary behavior when using macOS ld vs lld, gold, etc

[Norvon]

LDFLAGS = -object_path_lto $PATH

https://clang.llvm.org/docs/CommandGuide/clang.html