Re: RFH: MIPS ld breaking .eh_frame data ...

[Richard Sandiford <richard at codesourcery dot com>]

David Daney <ddaney@avtrex.com> writes:
> It seems that by using PC relative augmentation, the number of 
> relocations in a shared object (in .eh_frame) is probably greatly 
> reduced.  Is this the reason for converting to PC relative addressing?

That's the main reason, but it was also motived by a correctness issue.
glibc doesn't (or at least didn't used to) terminate .eh_frame correctly,
and the glibc maintainers would not accept a patch to change it.  The lack
of termination doesn't matter in practice if .eh_frame_hdr has a binary
search table, because we generally use that table to look up individual
FDEs, and don't walk from the beginning of .eh_frame to the end at
run time.  But:

		  /* If a shared library uses absolute pointers
		     which we cannot turn into PC relative,
		     don't create the binary search table,
		     since it is affected by runtime relocations.  */

So without this optimisation, MIPS .eh_frame_hdrs would not have
a binary search table, and the exception routines would sometimes
walk off the end of .eh_frame.

>  From looking at the code it looks like the FDE header is being properly 
> relocated, all that needs to be done is to fix any DW_CFA_set_loc 
> offsets as well and it would work.
>
> Is this the fix you are thinking of?

I haven't looked at the testcase or code at all yet, sorry ;)
I can't really say yet.

Richard