Message-ID: <4ACB54AC.30502@cwilson.fastmail.fm>
Date: Tue, 06 Oct 2009 10:31:08 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: CFA: pseudo-reloc v2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple