CFA: pseudo-reloc v2

Charles Wilson cygwin@cwilson.fastmail.fm
Tue Oct 6 14:34:00 GMT 2009


Corinna wrote:
> The important question here is, will v1 pseudo relocs work as
> before? Since we simply don't have applications with v2 pseudo
> relocs yet and since the idea is to switch to v2 after giving it a
> longer grace period, the v2 functionality is just prep work. I'm
> all for supporting v2 right from 1.7.1, as long as it's guranteed
> that the v1 code path behaves as before.

v1 relocs continue to work as before, at least according to my tests
with a current ld.

For current binutils since CVS 2008-11-14 (which includes cygwin
binutils version 2.19.51-1 released on 2009-07-05) AND for older
binutils (such as cygwin 20080624-2), the relocation list is v1 and
looks like the following (unless --enable-runtime-pseudo-relocs-v2 is
explicitly specified):

__RUNTIME_PSEUDO_RELOC_LIST__:
  .dword ?  ; .addend (first reloc entry)
  .dword ?  ; .target
  .dword ?  ; .addend (second reloc entry)
  .dword ?  ; .target
  ...
  .dword ?  ; .addend (last reloc entry)
  .dword ?  ; .target
__RUNTIME_PSEUDO_RELOC_LIST_END__:

This works, according to my simple tests -- I haven't yet used it for a
"big" package "in real life", but I have no concerns about that. The v1
reloc code is really pretty simple (on the runtime side; both v1 and v2
are a hairy nightmare on the ld side), so if it works for the simple
test case -- including across fork() -- I'm confident it will work in
general.

v2 relocs will look like this:

__RUNTIME_PSEUDO_RELOC_LIST__:
  .dword 0  ; .magic1
  .dword 0  ; .magic2
  .dword 0  ; .version = RP_VERSION_N
  .dword ?  ; .addend (first actual reloc entry)
  .dword ?  ; .target
  .dword ?  ; .addend (second reloc entry)
  .dword ?  ; .target
  ...
  .dword ?  ; .addend (last reloc entry)
  .dword ?  ; .target
__RUNTIME_PSEUDO_RELOC_LIST_END__:

It is POSSIBLE to create a "v1" relocation list using the form above,
with .version = RP_VERSION_1, and the runtime relocation code will
support that. However, at present binutils does not generate a v1
relocation list with the 3-DWORD header for pe386 -- although it may do
so for pep386. I thought that newer binutils DID in fact use this
variant structure, but I just stepped thru it and I was wrong. I'll need
to update the comments in pseudo-reloc.c that I posted last night.

BTW, the test cases I posted here:
http://cygwin.com/ml/cygwin-developers/2009-10/msg00052.html
each build two versions: both -v1 and -v2, so I've been testing both
versions all along.

--
Chuck




More information about the Cygwin-developers mailing list