Add support for R_HEX_GOT_11_X/R_HEX_GOT_32_6_X.
Create a new relocation expression, HEXAGON_GOT to handle the got offset calculation.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
ELF/InputSection.cpp | ||
---|---|---|
549 ↗ | (On Diff #167815) | You are not using A nor P, so this expression is a constant. Is this code correct? |
ELF/InputSection.cpp | ||
---|---|---|
549 ↗ | (On Diff #167815) | The ABI describes the added relocations (type G) as the, "offset into global offset table for the entry of a symbol". Access to the symbol starts first by getting the base of the global offset table, The immediate ##bar@GOT is calculated as Sym.getGotVA() - In.GotPLT->getVA(). I checked this with some existing hexagon code and everything seemed ok. |
This is the link:
https://developer.qualcomm.com/download/hexagon/hexagon-application-binary-interface-specification.zip
There is a click-thru sign-in that is required to get to the document. I could not find a copy that was otherwise accessible.
I need to contact a legal team before downloading the PDF since it requires me to agree with a Terms of Use to download it. I'll get back to you.
OK, so looks like I cannot agree with the Terms of Use to download the spec. The exact words of the Terms of Use doesn't matter (though I'm not a lawyer), but in general, you cannot require a maintainer to sign a random legal document only to review your patch. Please consider consulting your legal team to make the spec publicly available if you can.
That said, fortunately, the only part I don't understand without the spec is the necessity of R_HEXAGON_GOT relocation type, and as per your explanation, I believe your patch is correct. So, LGTM. Please go ahead and submit.
But again, please consider contacting your legal team to publish the documentation. That makes my life as a maintainer much easier. Thanks!