This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] Adding architecture name into saved object filename
ClosedPublic

Authored by steven_wu on Apr 19 2019, 2:29 PM.

Details

Summary

For ThinLTOCodegenerator, it has an option to save the object file
outputs into a directory which is essential for debug info. Tools like lldb
and dsymutil will look for these object files for debug info.

On Darwin platform, you can link fat binaries with one single clang
driver invocation like:
$ clang -arch x86_64 -arch i386 -Wl,-object_path_lto,$TMPDIR ...
Unfornately, the output object files for one architecture is going to
overwrite the previous ones and one architecture slice will end up with
no debug info. One example for this is to turn on ThinLTO for sanitizer
dylibs in compiler-rt project.

To fix the issue, add the name for the architecture into the name of the
output object file.

rdar://problem/35482935

Diff Detail

Repository
rL LLVM

Event Timeline

steven_wu created this revision.Apr 19 2019, 2:29 PM
Herald added a project: Restricted Project. · View Herald Transcript

Is there a good way to test this?

Is there a good way to test this?

Not currently in LLVM. It might be possible to add a test in clang repo which requires DARWIN and ld64.

Is there a good way to test this?

Not currently in LLVM. It might be possible to add a test in clang repo which requires DARWIN and ld64.

Maybe we can split out the function to generate the filename, and add a unit test for that?

Is there a good way to test this?

Not currently in LLVM. It might be possible to add a test in clang repo which requires DARWIN and ld64.

Maybe we can split out the function to generate the filename, and add a unit test for that?

That almost looks like a test for path::append. Not sure if there is much value to add that.

Is there a good way to test this?

Not currently in LLVM. It might be possible to add a test in clang repo which requires DARWIN and ld64.

Maybe we can split out the function to generate the filename, and add a unit test for that?

That almost looks like a test for path::append. Not sure if there is much value to add that.

What about an llvm-lto test? Is there a way to make it trigger this case?

My concern is that this is a subtle requirement, and it would be easy to regress without a test.

steven_wu updated this revision to Diff 195957.Apr 19 2019, 7:08 PM

Add tests for the change. There is acutally an easy to test with llvm-lto

Also clean up the interface.

This revision is now accepted and ready to land.Apr 29 2019, 2:28 PM
This revision was automatically updated to reflect the committed changes.