[PATCH] D75131: [XCOFF][AIX] Enable -r option for llvm-objdump

[Jason Liu via Phabricator via llvm-commits]

jasonliu marked an inline comment as done.
jasonliu added inline comments.


================
Comment at: llvm/lib/Object/XCOFFObjectFile.cpp:362
+  }
+  llvm_unreachable("Cannot find the containing section for this relocation.");
 }
----------------
jhenderson wrote:
> jasonliu wrote:
> > davidb wrote:
> > > jhenderson wrote:
> > > > Is this really unreachable? Could you get to here with an object with some invalid relocation or section property?
> > > Agree. I think a relocation with an invalid r_vaddr could fall through this.
> > I see. I could make them report_fatal_error instead. 
> See my earlier comment. Please use `llvm::Expected` if possible, not `report_fatal_error`.
As mentioned below, I find it a bit challenge to change the existing interface to return llvm::Expected. Although this one might not be as hard as getRelocationSymbol, it is still a non-trivial task after some investigation (i.e. there are python script actually depending on existing interface if I'm not mistaken). So I'm thinking to proceed with some less resistant way.

Other target for this function will return the virtual address stored in the relocation entry without checking and calculation. 
Presumably, the caller of this function would have to check if the range is valid, or they would just happy to accept any invalid value and print it.
So my plan is, for XCOFF target, we could return a magic number (std::numeric_limits<uint64_t>::max()) so that if anyone bother to check the range, they know it's invalid, and if they don't want to check it, they could still proceed gracefully just like other target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75131