[PATCH] D119049: [LLD] Allow usage of LLD as a library

[Alexandre Ganea via Phabricator via llvm-commits]

aganea added a comment.

Hello @srj ! Sorry for the late answer.

In D119049#4421785 <https://reviews.llvm.org/D119049#4421785>, @srj wrote:

> Hi, I'm trying to update Halide's usage of this API to work properly, there are a few things that aren't clear to me:
>
> - It appears that `lldMain` is now the preferred entry points; I presume that `unsafeLldMain` and `safeLldMain` are intended for internal use only?

Yes.

> - It's not clear to me whether use of `CrashRecoveryContext` with this API is required or optional. (We previously didn't use it, though we did wrap calls to the old entry point with `std::signal()` usage to save and restore signal handlers.)

The `CrashRecoveryContext` is mandatory in this context since `lldMain` goes through `safeLldMain` which also happens to clean the context before the function exists (which is not what regular `lld.exe` does, it simply leaks all buffers for faster exit). My thinking is that `lldMain` will be used in long-running applications like a daemon. If you have suggestions/improvements for the API, let me know.

> - It's not clear to me whether we should use `exitLld()` or not -- in the event of failure, we always previously exited anyway, but it appears that `exitLld()` always exits with SIGABRT, which would break the existing contract of our tool (which would exit via `exit(1)`). Does `exitLld()` do special cleanup (eg, temp file cleanup) that would be missed otherwise?

The `SIGABRT` you're seeing is simply because `exitLld()` forwards the crash code through this: https://github.com/llvm/llvm-project/blob/main/lld/Common/ErrorHandler.cpp#L100 - you can set `r.retCode = 1;` in your code before calling `exitLld()` to avoid this situation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119049/new/

https://reviews.llvm.org/D119049