This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy] Make .build-id linking atomic
ClosedPublic

Authored by jakehehrlich on Mar 6 2019, 11:10 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

jakehehrlich created this revision.Mar 6 2019, 11:10 AM
Herald added a project: Restricted Project. · View Herald Transcript

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"

jakehehrlich marked 4 inline comments as done.
  1. Fixed typos
  2. Added context (sorry about that, rookie mistake)
jhenderson added inline comments.Mar 11 2019, 2:59 AM
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
199–200

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.

jakehehrlich added inline comments.Mar 13 2019, 1:43 PM
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.

jhenderson added inline comments.Mar 14 2019, 2:58 AM
llvm/include/llvm/Support/FileSystem.h
770

Then the comments below are wrong!

jakehehrlich marked 5 inline comments as done.
jakehehrlich added inline comments.Mar 14 2019, 3:12 PM
llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp
199–200

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.

jhenderson accepted this revision.EditedMar 15 2019, 2:43 AM

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.

This revision is now accepted and ready to land.Mar 15 2019, 2:43 AM

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();
}
rupprecht accepted this revision.Mar 15 2019, 10:52 AM
rupprecht marked an inline comment as done.

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.

199–200

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?
Using c_str() seems like a good idea anyway.

It looks like rL356404 committed this without referencing the differential revision or addressing some of the comments

jakehehrlich closed this revision.Mar 22 2019, 12:49 PM
jakehehrlich marked an inline comment as done.

Right sorry about that.