[PATCH] D44562: [ELF] Rework debug line parsing to use llvm::Error and callbacks (LLD-side)

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 29 01:43:20 PDT 2018


jhenderson added inline comments.


================
Comment at: Common/ErrorHandler.cpp:86-91
+void ErrorHandler::remark(const Twine &Msg) {
+  std::lock_guard<std::mutex> Lock(Mu);
+  newline(ErrorOS, Msg);
+  print("remark: ", raw_ostream::BLUE);
+  *ErrorOS << Msg << "\n";
+}
----------------
ruiu wrote:
> Honestly I don't think we want to add a new level of error messages, as I think error() for errors, warning() for warnings and message() for non-error messages is enough. If something needs to be fixed, it should be an error or a warning. If something doesn't have to be fixed, lld shouldn't print out anything. A situation like "verbose messages are printed out but you can ignore them" isn't actionable and thus not desirable.
> 
> So, can you choose either (1) show it as a warning or (2) don't show anything?
Okay, I have no problem making it a warning. I think this might be a safer course than not printing anything.  If undefined symbol messages are incomplete, due to a problem in the input, it might be possible for users to fix it, depending on the nature of the problem (e.g. bogus hand-written debug_line assembly), and therefore allowing them to see the useful error information, allowing them to more quickly identify the problem. I could also see us potentially using this function in the future to produce other informational messages, or implement other features, without always emitting an error, so a warning would be appropriate here too.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D44562





More information about the llvm-commits mailing list