This is an archive of the discontinued LLVM Phabricator instance.

Handle Windows drive letters and ".." for --reproduce.
ClosedPublic

Authored by ruiu on Apr 26 2016, 12:45 PM.

Details

Summary

When --reproduce <path> is given, then we need to concatenate input
file paths to the given path to save input files to the directory.
Previously, path concatenation didn't handle Windows drive letters
so it could generate invalid paths such as "C:\D:\foo". It also didn't
handle ".." path components, so it could produce some bad paths
such as "foo/../../etc/passwd".

In this patch, Windows drive letters and ".." are removed before
concatenating paths.

Diff Detail

Repository
rL LLVM

Event Timeline

ruiu updated this revision to Diff 55070.Apr 26 2016, 12:45 PM
ruiu retitled this revision from to Handle Windows drive letters and ".." for --reproduce..
ruiu updated this object.
ruiu added a reviewer: davide.
ruiu added a subscriber: llvm-commits.
davide added inline comments.Apr 26 2016, 12:53 PM
ELF/Driver.cpp
106 ↗(On Diff #55070)

concatenating.

258 ↗(On Diff #55070)

I prefer dumpLinkerInvocation still.

272 ↗(On Diff #55070)

We use unsigned everywhere else in the code base, try to be consistent or change all the other occurrences.

davide edited edge metadata.Apr 26 2016, 12:55 PM

My understanding is that you're trying to remove all the ".." from T before doing the concatenation.
What happens if you have ../foo and ../../foo ? Would they collide? If not, can you please add a test to ensure this won't happen?

Thanks for your work, btw.

ruiu added inline comments.Apr 26 2016, 12:59 PM
ELF/Driver.cpp
258 ↗(On Diff #55070)

To me this name is more plain and therefore good. It just logs command line -- I can tell it would obviously have no side effect (except writing a log somewhere) just by looking at the name. But dumpLinkerInvocation sounds something more complex.

272 ↗(On Diff #55070)

I don't think we do. I actually use size_t where it means the size of an array. This is also technically accurate (even though it is unrealistic that we have more than 2^32 arguments).

ruiu added a comment.Apr 26 2016, 1:02 PM

If we have "../foo" and "../../foo", then one will overwrite the other.

davide added inline comments.Apr 26 2016, 1:20 PM
ELF/Driver.cpp
258 ↗(On Diff #55070)

As you wish. Discussing this is probably not worth more time.

272 ↗(On Diff #55070)

I think these should be changed then:

Writer.cpp: for (unsigned I = 0; I < OutputSections.size(); ++I) {
OutputSections.cpp: for (unsigned I = 0, N = Offsets.size(); I != N; ++I) {

I don't care which one we use just try to use the same everywhere. Feel free to change in another patch.

In D19551#412677, @ruiu wrote:

If we have "../foo" and "../../foo", then one will overwrite the other.

hmm, that's undesiderable. I think converting to absolute paths before appending *might* fix the issue, although I'd like to hear your opinion on it.

ruiu added a comment.Apr 26 2016, 1:29 PM

Right. That's surely undesirable, but I guess it wouldn't happen in reality. Full path would be fine, but that would be more tricky to test (because it is not easy to concatenate two absolute paths in tests), so I think this is fine. Since this is a developer option, we can change its behavior later.

OK, not entirely convinced, but enough to make progress.
Should we change the logCommandLine() invocation to include the transformed paths?

ruiu added a comment.Apr 26 2016, 1:38 PM

If we concatenate Config->Reproduce and "invocation.txt" before passing it
to logCommandline, we need to decompose the path to get the directory part
which is exactly Config->Reproducible, so it is better to not concatenate them.

In D19551#412732, @ruiu wrote:

If we concatenate Config->Reproduce and "invocation.txt" before passing it
to logCommandline, we need to decompose the path to get the directory part
which is exactly Config->Reproducible, so it is better to not concatenate them.

lgtm.

This revision was automatically updated to reflect the committed changes.