This change makes linking into .build-id atomic and safe to use. Some users under particular workflows are reporting that this races more than half the time under particular conditions.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Missing context is making it hard for me to review the Path changes.
llvm/include/llvm/Support/FileSystem.h | ||
---|---|---|
770 | model -> Model, I assume to match the variable name? | |
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
186 | odds a conflict -> odds of a conflict | |
195 | seriouslly -> seriously | |
202 | "to he same"? Not sure if that should be "to some" or "to the same" |
llvm/include/llvm/Support/FileSystem.h | ||
---|---|---|
770 | This still doesn't match the variable name? | |
772 | Rogue \a? | |
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
205–206 | It may depend on the reporting site, but I believe that this will throw away the potentially useful information in EC. I think you need to add EC's message to the string error to avoid this. |
llvm/include/llvm/Support/FileSystem.h | ||
---|---|---|
770 | Sorry I had a draft comment about this and was waiting to post it once I uploaded context....and then I just didn't; whoops. The comments were just copied from the documentation below. |
llvm/include/llvm/Support/FileSystem.h | ||
---|---|---|
770 | Then the comments below are wrong! |
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
---|---|---|
205–206 | I looked at the implementation of createStringError. It just calls make_error which in turn calls the StringError constructor which does not include the error code unfortunately so your concern was correct. I added a function here to resolve this issue. |
LGTM. It might be worth getting somebody who has worked more on stuff in the Support library before to review this too, but I'll leave that up to you.
I just do not feel I am a good person to review/accept that, overall looks OK for my eye though,
a minor nit/question/suggestion is inline.
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
---|---|---|
214 | Seems here and above you could use SmallString::c_str()? It's just implemented very close to this I think: const char* c_str() { this->push_back(0); this->pop_back(); return this->data(); } |
Just a couple nits, overall lgtm
llvm/lib/Support/Path.cpp | ||
---|---|---|
756 | Can you preserve the // Null terminate. comment here? | |
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp | ||
168 | Why the parens here? This expands to: "%%%%%%%%" "%%%%%%%%" "%%%%%%%%" "%%%%%%%%" which is implicitly joined together. Is it just for clarity, or is it actually required? Either way -- either MODEL_16 should also be parens'd, or neither should be parens'd. | |
205–206 | Wow, this is kinda a wtf. From Error.cpp: StringError::StringError(std::error_code EC, const Twine &S) : Msg(S.str()), EC(EC) {} StringError::StringError(const Twine &S, std::error_code EC) : Msg(S.str()), EC(EC), PrintMsgOnly(true) {} void StringError::log(raw_ostream &OS) const { if (PrintMsgOnly) { OS << Msg; } else { OS << EC.message(); if (!Msg.empty()) OS << (" " + Msg); } } So, StringError(EC, "foo") will print "error code: foo", but StringError("foo", EC) will just print "foo". createStringError() uses the StringError("foo", EC) constructor. That seems very strange. I'm totally in favor of creating a makeStringError() method here to workaround that, but we should probably fix that. | |
214 | Why is it even necessary to do this here? Doesn't createUniquePath null terminate it? |
It looks like rL356404 committed this without referencing the differential revision or addressing some of the comments
model -> Model, I assume to match the variable name?