search

riscv-non-isa / riscv-elf-psabi-doc

A RISC-V ELF psABI Document
https://jira.riscv.org/browse/RVG-4
Creative Commons Attribution 4.0 International
663 stars 158 forks source link

Add ePIC relocations and rewrite rules #405

Open luismarques opened 8 months ago

luismarques commented 8 months ago

Continuing to follow up on the request to decompose the ePIC PR into multiple PRs, this PR adds the ePIC relocations and rewrite rules.

kito-cheng commented 5 months ago

@rui314 @maskray any comments? generally I would like get at least one more LGTM from someone other than GNU folk, but I know it's kinda embedded stuffs which you may not interested on that, so it's fine if no comment, but I would like to make sure it's at least not looks insane to linker expert.

@Nelson1225 You and me has spend times on discussion this before, and we both like this, so I assume you are OK with this, but I guess it would be great to get your explicitly LGTM here again :)

MaskRay commented 5 months ago

I am happy with the GP-relative relocation part (also used by the FDPIC ABI proposal), but I am afraid I am concerned of R_RISCV_EPIC_* relocations. Commented here https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/343#issuecomment-1926279418

Also CC @sorear

MaskRay commented 4 months ago

I don't have a good understanding of the use cases for embedded systems that need PIC but not shared libraries. Is there any freely source available example of something that would use this? If it's needed for a commercial RTOS, is there at least a public manual or datasheet?

@MaskRay Was your comment questioning the existence of the use case for ePIC without shared libraries, suggesting that ePIC should be a special case of FDPIC, or something else?

Assuming that the use case is valid, the general approach looks good. Relocation behavior needs to be described in the language of externally observable linker behavior, not implementation details like synthesized non-dynamic relocations. I think we also need an absolute option, at least for weak symbols but it may be useful more generally.

My comment is questioning the existence of the use case for ePIC without shared libraries. I think we should consider FDPIC, which works with MMU-less and MMU systems, supports dynamic libraries. After FDPIC support, we can figure out whether there is still ePIC need. (I kinda suspect no.)