[PATCH] D87987: [llvm-objcopy][NFC] refactor error handling. part 3.

George Rimar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 28 23:49:02 PDT 2020


grimar added a comment.

In D87987#2297596 <https://reviews.llvm.org/D87987#2297596>, @jhenderson wrote:

> Before you go too much further with this, I'd like some comments from others on the approach. The fact that this code is far more extensive and has far more error paths suggests to me that we might be on the wrong approach here, and perhaps we should actually be using the error handler callback approach after all. @grimar/@rupprecht/@MaskRay - any thoughts?

I have 2 general comments/thoughts atm:

1. I've noticed that the code tries to address 2 a bit different situations currently: a) Cases that fix the `unwrapOrError`: like `unwrapOrError(HeadersFile.program_headers())` which seems are trying to fix places related to broken inputs which were never tested before I think. b) Cases that are tested and report errors, like: `error("program header with offset 0x" + Twine::utohexstr(Phdr.p_offset) + ....`.

I think for start we should probably focus on (b) and probably can keep `unwrapOrError` untouched until we convert them and add tests.

2. Regarding the error handler callback suggested. I am thinking about something that is implemented in LLD. I.e. a error state is remembered and a error is reported via callback. Then we are trying to stop execution and exit at a convenient place. @jhenderson, did you mean something like this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87987



More information about the llvm-commits mailing list