This is an archive of the discontinued LLVM Phabricator instance.

lld-link: Make /linkrepro: take a filename, not a directory.
ClosedPublic

Authored by thakis on Sep 11 2019, 12:51 PM.

Details

Summary

This makes lld-link behave like ld.lld. I don't see a reason for
the two drivers to have different behavior here.

While here, also make lld-link add a version.txt to the tar, like
ld.lld does.

Diff Detail

Repository
rL LLVM

Event Timeline

thakis created this revision.Sep 11 2019, 12:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 11 2019, 12:51 PM
ruiu accepted this revision.Sep 12 2019, 12:35 AM

LGTM

Thank you for doing this.

This revision is now accepted and ready to land.Sep 12 2019, 12:35 AM
hans added a subscriber: hans.Sep 12 2019, 12:39 AM

Nice!

But is there no help text or user manual that needs to be updated?

Nice!

But is there no help text or user manual that needs to be updated?

The help text is "Dump linker invocation and input files for debugging" which is noncommittal enough to not need changing :) Once this and D67456 are in I want to look at also supporting the env var for linkrepro like in the ELF port (and it should work even with /lldignoreenv set, since it doesn't affect the normal output) and port the recent ELF changes that change the help text to make it look less like a lld dev debug flag; I was thinking about changing the help text then.

This revision was automatically updated to reflect the committed changes.

I realized why the behavior was different: link.exe has a /linkrepro: flag that behaves like lld-link's used to (https://www.geoffchappell.com/studies/msvc/link/link/options/linkrepro.htm?tx=37). It also honors a link_repro env var.

So I think I'll have to revert this, and add a comment explaining why things are different.

pcc added a comment.Sep 23 2019, 12:49 PM

I realized why the behavior was different: link.exe has a /linkrepro: flag that behaves like lld-link's used to (https://www.geoffchappell.com/studies/msvc/link/link/options/linkrepro.htm?tx=37). It also honors a link_repro env var.

Yes, that's why I originally made this take a directory instead of a file name.

So I think I'll have to revert this, and add a comment explaining why things are different.

I guess another option would be to rename this flag to /lldlinkrepro, which would let us implement link.exe-compatible behaviour under /linkrepro in the future.