https://sourceware.org/bugzilla/show_bug.cgi?id=32789
--- Comment #2 from Indu Bhagat <indu.bhagat at oracle dot com> --- Right. In the SFrame stack trace format, the FDEs (function descriptor Entry) are in sorted order of the start PC of the functions in the ELF file, if SFRAME_F_FDE_SORTED flag is set. It is true that if the .text.* sections in the relocatable link are then loaded in a different relative order of each other, the said SFRAME_F_FDE_SORTED property in the section is violated. If the order is not changed, the given SFrame section can be used as is (with some changes be made as noted in https://sourceware.org/pipermail/binutils/2025-March/139925.html).. So then, if the .text.* sections in the relocatable link are then loaded in a different relative order of each other, there are two options for the entity dealing with the relocatable file: - The SFrame section's SFRAME_F_FDE_SORTED flag property is reset. - The SFrame section's FDEs are rearranged in sorted order if SFRAME_F_FDE_SORTED property is desirable. [In case of .eh_frame, there is no .eh_frame_hdr (effectively the lookup table) in relocatable link for this being one of the reason I assume.] -- You are receiving this mail because: You are on the CC list for the bug.
