Why: From Kai's original post,
By the current implementation there are several problems I see.
a) Auto-imported variables do not work in all cases (e.g. structure
field addresses, etc).
b) Each relocation leads to additional code needed.
? c) For 64-bit different relocation sizes are possible.
d) If the relocations are placed within custom read-only sections
the pseudo-relocator produces an assertation by attempting to write
to read-only addresses.
While we (probably) don't care about the 64 bit issues as cygwin is
still strictly a 32 bit beast, it appears as though Kai's new scheme
allows (1) auto-import to work with "complex" data types, and (2) with
relocs in read-only sections -- and the runtime component (that is,
pseudo-reloc.c) supports both current pseudo-relocs (now called "v1")
and the new style ("v2").
But this will all need testing, of course -- especially to ensure that
it doesn't break existing "v1" relocs. I just wanted to know -- since
Kai's changes have now been committed to binutils CVS, although "v1"
remains ld's default for 32 bit PE platforms -- if the new cygwin-1.7
runtime component should support the new "v2" style relocations, so that
we can play with ld's new --enable-runtime-pseudo-reloc-v2 option.
Finally, there's this:
On Mon, 3 Nov 2008 10:23:04 -0500, Christopher Faylor said:
I would be very interested in seeing this added for all PE targets.
BTW, one part of Kai's change (now in binutils) changes this (for PE
32bit):
- link_info.pei386_runtime_pseudo_reloc = -1;
+ link_info.pei386_runtime_pseudo_reloc = 1; /* Use by default version
1. */
That is, we will always act as tho --enable-runtime-pseudo-reloc were
specified on the command line. This means the existing behavior ("-1" --
where we DO pseudo-relocs, but warn about it unless the user explicitly
specified --enable-runtime-pseudo-reloc) is changed to "just DO it and
be quiet" unless the user specifically disables it.
I guess it's about time we made that change, but there was no discussion
of this particular bit.
--
Chuck