Two reasons: - we could be able to infer the arch from the inputs (not implemented yet, tho) => it's a bit immature to die early when -arch is not specified - and if a missing response file is passed in, the fatal() error on missing -arch prevented lld from diagnosing this. So this is also a bit confusing. (LD64 doesn't have this problem) This patch delay the fatal() until after parsing input files.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Why do we need this? We currently print ld64.lld: error: cannot open @fooasdfdsaf.txt: No such file or directory which seems fine?
None of the other lld ports do this.
Oh, I see that function is new. Probably should do this for all ports in this CL then if you think this is worth doing.
lld/MachO/DriverUtils.cpp | ||
---|---|---|
86 ↗ | (On Diff #376423) | I see this is a new function. Since this will be the only caller, can we add only the arguments we need, so that we don't have to pass all these default args? |
91 ↗ | (On Diff #376423) | Can we use checkError() instead? |
Hmm which version printed this?
Right now all i'm getting was ("must specify -arch") for the macho port, which took me awhile to realise I had a typo in my response file name ..
bin/ld64.lld @foobar.txt ld64.lld: error: must specify -arch
None of the other lld ports do this.
ELF seems to have it:
$ bin/ld.lld @foobar.txt ld.lld: error: cannot open @foobar.txt: No such file or directory
lld/MachO/DriverUtils.cpp | ||
---|---|---|
86 ↗ | (On Diff #376423) | ok, will make these optional params |
Hmm which version printed this?
Trunk. (I did pass a -arch flag though.)
ELF seems to have it:
Can you check how it does it? It can't call that function that doesn't yet exist :)
(I guess we error out due to missing -arch before trying to open "@foo" as input file in MachO, which is why the -arch error is printed before the rsp error. Almost all users will use lld through the clang driver though, so in practice -arch will always be present.)
Oh, I see what you're saying. Right, ELF doesn't explicitly check for the response file not found, either. Instead it'd just try to load it as an input file later if it's previously fail to expand the @foo.txt .
IMO, that's a bit confusing - the cl::ExpandResponseFiles() today already returns a bool flag to indicate whether it succeeded - callers should probably check it. (Neither macho nor elf does that today). My other patch only expand the ExpandResponseFiles only expands the function to include more error info ...
Happy to apply the same change here over to elf (probably in a separate patch tho).
lld/MachO/Driver.cpp | ||
---|---|---|
1347 | I'm not sure how I feel about having all this code about a dummy struct just so we can avoid the typo scenario you mentioned. To me, it feels like an indirection just to get to the actual root cause. What's the difference between this and moving createTargetInfo here instead? It seems like the same result can be achieved and it's easier to reason about. I'm curious to know what others think tho... |
To be honest, I'm not sure this is really worth it. Almost everyone will invoke lld through the compiler driver.
But if you do want to have a nicer diag for missing rsp files, I like your previous approach of emitting a diag there better (assuming we add it to all drivers, and add the default args so the driver changes are small).
But if you do want to have a nicer diag for missing rsp files, I like your previous approach of emitting a diag there better (assuming we add it to all drivers, and add the default args so the driver changes are small).
The assumption in the previous patch was that if the util failed to read a foo from @foo as a file then, then it's an error - that's kind of wrong because it's too early for it to know - foo could have meant to be some other parameter (eg., @ loader_path)
Almost everyone will invoke lld through the compiler driver.
this may be true - but in general i still think it's worth it to diagnose errors correctly rather than giving some misleading ones (esp. as stuff gets more complicated). Also, there's still this unimplemented feature of inferring from input files - so perhaps it really shouldn't complain about unknown arch until *after* inputs have been parsed.
lld/MachO/Driver.cpp | ||
---|---|---|
1347 | we can't move it because other steps needed at least some reference to the target (caveat: without overhauling a few things, which I could try ...) |
I'm not sure how I feel about having all this code about a dummy struct just so we can avoid the typo scenario you mentioned. To me, it feels like an indirection just to get to the actual root cause. What's the difference between this and moving createTargetInfo here instead? It seems like the same result can be achieved and it's easier to reason about.
I'm curious to know what others think tho...