Page MenuHomePhabricator

MC: force eager evaluation of relocations in `.debug_info`
Needs ReviewPublic

Authored by compnerd on Jul 20 2022, 3:29 PM.

Details

Reviewers
MaskRay
jrtc27
Summary

Force eager evaluation of symbolic difference on debug_info which is
required to be resolved eagerly for fission as dwo sections may not
contain relocations.

Fixes: #56642

Diff Detail

Event Timeline

compnerd created this revision.Jul 20 2022, 3:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 20 2022, 3:29 PM
compnerd requested review of this revision.Jul 20 2022, 3:29 PM

This does not fix the incompatibility with RISC-V linker relaxation. This changes DW_AT_high_pc from a length to (pre-DWARF-v4) an address.
The address needs to be relocated as well. The correct approach is to use .debug_addr indirection via DW_FORM_addrx.

This is useful with linker relaxation, though, as it can decrease the number of relocations.

https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#code-addresses I am going to revise some paragraphs about DWARF.

Note: with -mno-relax this will increase the number of relocations.

MaskRay requested changes to this revision.Jul 20 2022, 3:47 PM
This revision now requires changes to proceed.Jul 20 2022, 3:47 PM

This does not fix the incompatibility with RISC-V linker relaxation. This changes DW_AT_high_pc from a length to (pre-DWARF-v4) an address.

Correct, this is not to fix the incompatibility with relaxation, it is to fix the compatibility with no relaxation and fission.

The address needs to be relocated as well. The correct approach is to use .debug_addr indirection via DW_FORM_addrx.

Interesting, do we have any target currently using that form?

This is useful with linker relaxation, though, as it can decrease the number of relocations.

https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#code-addresses I am going to revise some paragraphs about DWARF.

Yes, this should be able to reduce the number of relocations at the cost of debug info size. However, given that we currently fail to emit the object file this seems like a good tradeoff.

MaskRay added a comment.EditedJul 21 2022, 10:36 AM

This does not fix the incompatibility with RISC-V linker relaxation. This changes DW_AT_high_pc from a length to (pre-DWARF-v4) an address.

Correct, this is not to fix the incompatibility with relaxation, it is to fix the compatibility with no relaxation and fission.

For -mno-relax code, using the length instead of the end address for DW_AT_high_pc leads to fewer relocations in the output.
MC should be able to resolve the pair of R_RISCV_ADD32/R_RISCV_SUB32 to a constant.

With this patch, there will be a relocation which cannot be resolved at assembler time, leading to larger output size.

The address needs to be relocated as well. The correct approach is to use .debug_addr indirection via DW_FORM_addrx.

Interesting, do we have any target currently using that form?

No. As you can see, for -mno-relax, DW_AT_high_pc is a constant which saves more space than using the end address (one relocation) or using a .debug_addr indirection to represent the end address (more expensive),
so it is unimplemented. I think GCC doesn't implement it as well, hence the silent broken output :)

This is useful with linker relaxation, though, as it can decrease the number of relocations.

https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#code-addresses I am going to revise some paragraphs about DWARF.

Yes, this should be able to reduce the number of relocations at the cost of debug info size. However, given that we currently fail to emit the object file this seems like a good tradeoff.

See above.

compnerd updated this revision to Diff 447446.Jul 25 2022, 1:11 PM
compnerd retitled this revision from CodeGen: use address form for DW_AT_high_pc on RISCV to MC: force eager evaluation of relocations in `.debug_info`.
compnerd edited the summary of this revision. (Show Details)
compnerd updated this revision to Diff 447450.Jul 25 2022, 1:22 PM