Page MenuHomePhabricator

[Remarks][LTO] Infer remarks file path from -object_path_lto
Needs RevisionPublic

Authored by thegameg on Nov 21 2019, 4:56 PM.

Details

Summary

In the common flow, remarks are expected to be in the .dSYM bundle after dsymutil collects them from the object files and creates a standalone remark file. After that, the linked binary and the .dSYM bundle are sufficient to execute, debug, and process the remarks.

Even if users pass -object_path_lto to the linker, we generate the temporary remark files based on the output file requested through -o, which is very inconvenient when users try to separate their intermediate products from their final products. This will leave intermediate remarks in the final products, like Frameworks or other bundles.

This patch will change that behavior to try to infer the remarks file path from the path specified in -object_path_lto.

It is a little messy as the driver will try to read flags that are intended to be passed to the linker, but for now, it's the only option and hasExportSymbolDirective is already doing this.

The cleaner way to do this would be to add an interface for the linker to specify the remark output file when setting up LTO.

Diff Detail

Event Timeline

thegameg created this revision.Nov 21 2019, 4:56 PM
steven_wu requested changes to this revision.Dec 2 2019, 9:12 AM
steven_wu added inline comments.
clang/docs/UsersManual.rst
363

The implementation doesn't check -flto is used. You don't need to document this part.

clang/lib/Driver/ToolChains/Darwin.cpp
433

You can use a filtered iterator here. Also I think the last argument of the same type wins, rather than the first one.

This is rather ugly. Can you let linker pass the file path to you through LTO interface, rather to infer that from -Xlinker or -Wl option?

This revision now requires changes to proceed.Dec 2 2019, 9:12 AM
thegameg marked an inline comment as done.Dec 2 2019, 10:40 AM
thegameg added inline comments.
clang/lib/Driver/ToolChains/Darwin.cpp
433

I agree with you here. The reasons I went for this approach is that it avoids adding remark-specific logic to the LTO interface and the linker. The linker would need to know how to build a remark filename based on things like the format or whether it's ThinLTO or not.

Thinking more about this, maybe the best option is to never pass the path to the remark file unless it's explicitly specified by the user, and let the LTOCodeGenerator create the file if asked (through another option like -lto-pass-remarks).

steven_wu added inline comments.Dec 2 2019, 10:55 AM
clang/lib/Driver/ToolChains/Darwin.cpp
433

I would argue that if LTO is missing the interface to support Remarks which is supported for normal compilation, adding an interface to libLTO is totally fine.

Using LTOCodeGenerator to write output remark file while writing out each object file sounds like a good idea.