Define relocations for ULEB128 value: R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128 #361
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Update the link of LLVM + LLD patch. |
rui314
reviewed
Jan 30, 2023
Define. Suggest: just specify the full names of the two new relocation types. |
kito-cheng
force-pushed
the
uleb128-reloc
branch
from
e6a905c to
333012a
Compare
kito-cheng
changed the title
kito-cheng
force-pushed
the
uleb128-reloc
branch
from
333012a to
02f4770
Compare
|
Update:
|
kito-cheng
force-pushed
the
uleb128-reloc
branch
from
02f4770 to
caddcb2
Compare
|
Changes:
|
|
LGTM, it have been expected to support this feature for a long time :) |
kito-cheng
force-pushed
the
uleb128-reloc
branch
from
caddcb2 to
bf3e94b
Compare
MaskRay
reviewed
Mar 30, 2023
MaskRay
reviewed
Mar 30, 2023
MaskRay
approved these changes
Mar 30, 2023
kito-cheng
force-pushed
the
uleb128-reloc
branch
from
bf3e94b to
8f1ad93
Compare
…_SUB_ULEB128 ULEB128 has used in DWARF and exception handling table, it used to record value, or record the distance between two symbols. The later one would be an issue for debug info and exception handling table, since the symbol address might updated during, then the value might incorrect after relaxation, some of those field has alternative encoding type, but some new field defined in DWARF 5 ins't provide alternative format other than ULEB128, e.g. DW_RLE_offset_pair, DW_RLE_startx_length, DW_RLE_startx_endx and DW_RLE_start_length. This PR basically same as #162, but updated to the trunk, and also document ULEB128 should not shrink the size of the data, since we never know the data used in where and does the length has recorded in somewhere or not, so this would be most safe way. binutils patch: https://sourceware.org/pipermail/binutils/2020-January/109672.html
kito-cheng
force-pushed
the
uleb128-reloc
branch
from
8f1ad93 to
96d6e19
Compare
|
Thanks everyone! gonna merge this! |
rui314
reviewed
Mar 30, 2023
| .2+| 60 .2+| SET_ULEB128 .2+| Static | _ULEB128_ .2+| Local label assignment <<uleb128-note,*note>> | ||
| <| S + A | ||
| .2+| 61 .2+| SUB_ULEB128 .2+| Static | _ULEB128_ .2+| Local label subtraction <<uleb128-note,*note>> | ||
| <| V - S + A |
There was a problem hiding this comment.
Actually I think this needs to be V - S - A for consistency with other SUB relocations.
There was a problem hiding this comment.
Good catch! it actually should be V - (S + A) but V -S - A would be consistency with others.
There was a problem hiding this comment.
hot-fix applied: 4f7de69
rui314
added a commit
to rui314/mold
that referenced
this pull request
Mar 31, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ULEB128 has used in DWARF and exception handling table, it used to record value, or record the distance between two symbols.
The later one would be an issue for debug info and exception handling table, since the symbol address might updated during, then the value might incorrect after relaxation, some of those field has alternative encoding type, but some new field defined in DWARF 5 ins't provide alternative format other than ULEB128, e.g. DW_RLE_offset_pair, DW_RLE_startx_length, DW_RLE_startx_endx and DW_RLE_start_length.
This PR basically same as #162, but updated to the trunk, and also document ULEB128 should not shrink the size of the data, since we never know the data used in where and does the length has recorded in somewhere or not, so this would be most safe way.
binutils patch: https://sourceware.org/pipermail/binutils/2020-January/109672.html
LLVM patch: https://reviews.llvm.org/D142879
LLD patch: https://reviews.llvm.org/D142880