Add R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128. #162
Conversation
|
Latest version of this patch: https://sourceware.org/pipermail/binutils/2020-January/109672.html There is two issue left in last PR:
@kuanlinchentw I am not family with binutils code especially for linker part, did you have handle this on your latest patch?
@MaskRay I think that issue is happens on assemble time, it seems like not related to linker time, and I think it's hard to describe that clear width, or maybe we could add note that and mention this should not shirk the size after relaxation? |
A uleb128 subtraction expression is only allowed both addresses in the same section currently.
The linker relaxation for uleb128 should not shrink even the value could be represented with shorter length, it should pad with 0x80 to keep the same length just as before the relaxation. |
@kuanlinchentw could you write this down into the document? https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#code-relax |
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
…_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
…_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
…_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
…_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
…_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
Sorry for re-createing the pull request, because I deleted my fork of the previous pull request (#124).
Since the number 58 is occupied by R_RISCV_IRELATIVE. So I update relocation numbers of R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128.