| Issue |
60599
|
| Summary |
[lld][ELF] Memory region overflow reported before merging .ARM.exidx sections
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
fdischner
|
When compiling only C sources, clang will generate a cantunwind .ARM.exidx section for each function and these will all be merged to a single entry in the final binary. However, lld will initially use the sum of all input sections when calculating the output section size. This may lead to a memory region overflow error even if the output section would fit after merging.
The issue seems to manifest here:
https://github.com/llvm/llvm-project/blob/981218e0f88c78fbf83e45abbae65d09b787f2c1/lld/ELF/Writer.cpp#L1614-L1621
Specifically, the call to `assignAddresses()` on line 1614 will check the sizes of the output sections against the memory region, but the exidx sections are not merged until the call to `finalizeSynthetic()` on line 1620.
Since we need to know the relative order of executable sections in order to perform the exidx merging, I think the only real solution is to somehow ignore the size of the .ARM.exidx output section on the first call to `assignAddresses()`. I've tested this by changing line 3371 to `size = 8` here:
https://github.com/llvm/llvm-project/blob/472393eff45002f60826f04fcc9261eeaa9f8691/lld/ELF/SyntheticSections.cpp#L3364-L3374
This essentially sets the size estimate to zero if no exidx sections are present and exactly 8 if one or more are present. I don't know whether this is an acceptable fix, because I'm not sure exactly what the initial size estimate is needed for or whether making it a fixed number has other unintended consequences. However, this change did allow me to link a project where lld previously reported an overflow of ~800 bytes, because there were over 100 cantunwind sections that all got merged into one.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
