-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[MC,llvm-readobj,yaml2obj] Support CREL relocation format #91280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
a0cfafb
24c0fbb
2418d62
516e44e
269bd6d
bacb181
c633fd3
eeeccb1
29b60ba
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -61,6 +61,9 @@ class MCTargetOptions { | |
|
||
bool Dwarf64 : 1; | ||
|
||
// Use CREL relocation format for ELF. | ||
bool Crel = false; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit here and elsewhere: Is "Crel" a correct way of spelling this? Should it be "CRel" (for "CompressedRelocations")? I'm assuming you're deliberately avoiding using CREL in this context, but an argument could be made for that too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If LLVM adopts https://llvm.org/docs/Proposals/VariableNames.html , I'd like to use |
||
|
||
// If true, prefer R_X86_64_[REX_]GOTPCRELX to R_X86_64_GOTPCREL on x86-64 | ||
// ELF. | ||
bool X86RelaxRelocations = true; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we are using a section type in the [LOOS, HIOS) range, is it worth using a dynamic tag in the [LOOS, HIOS) range.
As an aside, would a tag containing the number of CRELs (NCREL for example). This in theory could be used to pre-allocate memory for an expanded CRELs. I don't think it is worth doing unless there is a clear need though. I could imagine most dynamic linkers iterating through the LEB directly.
Although not strictly necessary a CREL Size (CRELSZ?) could be useful for a consumer to read all the CRELs into memory without having to read the header first to find the size. Again not worth doing unless we have a definite need for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit message mentions:
I tentatively think it is not worth the trouble to avoid the generic range.
I've thought about this but believe CRELSZ is not so necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to avoid generic numbers for dynamic tags/section types etc, except possibly generic numbers that are a long way from the "normal" range. The reason for this is we don't know what values are going to get standardised, assuming this feature even gets accepted into the standard. If, for example, another feature gets accepted into the standard before CREL, it might use up the slot you've "allocated" for the DT_CREL here, which could cause problems with loaders that have supported the experimental CREL implementation. On the other hand, a different special number (whether in a dedicated range or otherwise) that isn't adjacent to the list will not have the issue of a potential clash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the concern but this is just impossible given the essential state of the generic ABI...
(I have some notes at https://maskray.me/blog/2024-05-26-evolution-of-elf-object-file-format#a-future-in-flux)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this comment. There's an active mailing list, where proposals are discussed and adopted, even if there's no fully published document, so a different proposal could easily come up whilst this is still under review. Perhaps it'll be implemented in GNU/Solaris/... initially with the same generic value. Whose meaning of the value should then win?
In the worst case, maybe the generic ABI list ends up rejecting this crel proposal. The values aren't reserved for LLVM usage, so the next proposal to come along will use those same values and we then have a clash between what LLVM wants to use the value for (and there might be objects out there using that value, if this feature is adopted in an LLVM release), which would cause us all sorts of headaches in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I have more bandwidth to implement the DT_CREL support for binutils and some loader implementations, I'll use 38.
This avoids the potential annoyance of picking a version initially and then needing to change it later, which could cause issues with toolchain/loader interop inconvenience.
In practice, achieving consensus between major ELF toolchain vendors like GNU and LLVM is enough to prevent conflicts...
The generic ABI hasn't seen a new
DT_*
addition besides RELR since 2013.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still disagree with this. Is it just me? What do @smithp35 and @dwblaikie think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1.
I've tried to pushback on using any standard range before it's been standardized (eg: #91280 (comment) #91280 (comment) ) but I haven't looked through the change completely to see all the enumerations used and how they're reserved, whether they use an extension space or what the argument is for them not using one.
Perhaps someone could summarize this aspect of the patch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed DT_CREL to 0x40000026 for now.
It's complex but the spec on sco.com might get further updates, but it doesn't matter if GNU and LLVM can be kept in sync and the specification is essentially in the public domain. https://news.ycombinator.com/item?id=40486068