https://sourceware.org/bugzilla/show_bug.cgi?id=27566
--- Comment #2 from Nelson Chu <nelsonc1225 at sourceware dot org> --- Therefore, when we are doing the LUI and PCREL relaxations (GP to symbol or c.lui to symbol, must cross the DATA_SEGMENT), * If "-z relro" isn't set, then we need to reserve at most "MAXPAGESIZE" for the padding of DATA_SEGMENT_ALIGN. * If "-z relro" is set, then we need to reserve at most "MAXPAGESIZE + COMMONPAGESIZE" for the padding of DATA_SEGMENT_ALIGN and DATA_SEGMENT_RELRO_END. I only see the related checks when we are doing the LUI to C.LUI relaxation. If we want to ensure safety, then we need to do the above checks both for the LUI and PCREL relaxations, when the range crosses the DATA_SEGMENT. But consider the code size improvement, we might also need to consider the "MAXPAGESIZE" for noreloc (or "MAXPAGESIZE + COMMONPAGESIZE" for relro) when relaxing LUI/PCREL RO symbol to GPREL, that will cause the current code size worst. I'm not sure if the safest approach is needed at the moment, because the embedded target (norelro) is currently not reporting any related errors. Therefore, I would suggest that - for the "-z relro", consider the "MAXPAGESIZE + COMMONPAGESIZE" size when doing the LUI and PCREL relaxations, and the target symbol is placed in the RO-data section. And maybe we could also change the size of "2*MAXPAGESIZE" to "MAXPAGESIZE + COMMONPAGESIZE" for the C.LUI relaxation check. Though Lifang's patch, which disable the LUI relaxation when relro (only for linux toolchain), should works, but I prefer to use a unified method (consider the PAGESIZE) to check all LUI, C.LUI and PCREL relaxations. -- You are receiving this mail because: You are on the CC list for the bug.
