Details
Diff Detail
- Repository
- rLLD LLVM Linker
- Build Status
Buildable 20560 Build 20560: arc lint + arc unit
Event Timeline
ELF/SyntheticSections.cpp | ||
---|---|---|
509–510 | Then we would not know which object file causes .eh_frame_hdr pcrel overflow. But if you think this information is minor, I can move the check to EhFrameHeader::writeTo() FdeVA is the address of the .eh_frame FDE entry. I think it is very unlikely to overflow |
As to FdeVA, I wanted to ask if it could theoretically overflow. Since the new FdeData struct takes 16 bytes anyway, there's no point to keep FdeVA uint32_t instead of uint64_t.
Can you investigate how many FdeData are instantiated for common exception-heavy large programs? If it is not that many (so that we don't have to optimize), we could just include Fde->Sec to all FdeData.
I read the code again, and I believe the easiest way to fix this without hurting the readability of the code is to move more code from EhFrameHeader::writeTo to EhFrame::getFdeData, so that getFdeData returns a ready-made .eh_frame_hdr table entries, instead of something that needs to be sorted and then be subtracted by some value. You can do that in getFdeData, not after getFdeData.
ELF/SyntheticSections.h | ||
---|---|---|
82–83 | Now you can use uint32_t, no? |
ELF/SyntheticSections.cpp | ||
---|---|---|
509–510 | uint32_t Pc -> uint64_t PcRel uint32_t FdeVA -> uint64_t FdeVARel |
Now you can use uint32_t, no?