Mail Archives: cygwin/2009/10/06/10:31:32
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
- Raw text -