cygwin-1.7, pseudo-reloc v2

Charles Wilson cygwin@cwilson.fastmail.fm
Mon Jan 26 22:57:00 GMT 2009


Christopher Faylor wrote:
> I think we have to leave it to the MinGW team to replace the two files
> in the mingw directory.

OK.

> If I am reading the DISCLAIMER file in the mingw-w64 directory correctly
> it seems like this is public-domain code so we should be able to use it.

Yes. This is restated here:
http://sourceware.org/ml/binutils/2008-11/msg00171.html
and here:
http://sourceforge.net/tracker/index.php?func=detail&aid=2537769&group_id=2435&atid=302435

> This file is linked into the executable and doesn't seem to reside in
> cygwin1.dll so it shouldn't have any effect on existing binaries.

True.

> Can anyone confirm that it works as advertised?  It will require linking
> an app which relies on this with the above object.  I don't think there
> is any reason to rebuild cygwin.  You just need that pseudo-reloc.o.

For basic tests, yes -- you could just link pseudo-reloc.o in advance of
libcygwin.a. It gets a little tricky when your test cases includes a DLL
that itself needs to import (and relocate) symbols from a second DLL.
Then you have to worry about exporting those symbols (by default the
functions from all .o's on the command line will be exported; however
the "normal" case excludes symbols that come from libcygwin.a); so a
little care is needed.

I found it easier to rebuild cygwin and install the updated libcygwin.a,
as described below.

> If it works, and I have no reason to think that it won't, would you mind
> checking this in, Chuck?

Well, the very very latest version of Kai's pseudo-reloc doesn't seem to
work in the app<--DLL<--DLL case. More below.

>> 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.
> 
> I always reset this to -1 when I release binutils.  Maybe it's time to
> stop doing that and just let the default through.

As Kai pointed out, the warning I mentioned is actually triggered by the
presence/absence of --enable-auto-import, NOT --enable-pseudo. So
really, link_info.pei386_runtime_pseudo_reloc = -1 is no different than
link_info.pei386_runtime_pseudo_reloc = 1, for cygwin.

####################################################

FWIW, the latest version of Kai's patch doesn't seem to work very well
on cygwin. With a slight additional modification (reversion) in his
code, -v1 can be made to work as currently while still requiring .text
and .rdata sections to be writable (as currently) -- that is, no
regressions.  But -v2 just seems completely bolluxed, and the
__write_data function doesn't seem to work properly.

As it happens, you *do* need to rebuild cygwin -- because (1) the
pseudo-reloc code needs to go in libcygwin.a (2) if you include
pseudo-reloc.o directly -- expecially in a DLL -- then you must take
great care not to export its symbols (symbols in libcygwin.a are
excluded automatically).  (Or you could play games with 'ar x' and
rebuilding your existing libcygwin.a manually; but that's a lot of
hassle AND makes it difficult to debug the relocation code...)

Plus, I'm not sure that
 (a) this code should call abort()
 (b) or that errors should be reported via fprintf.

Test cases taken from Egor Duda's original ones when the pseudo-reloc
stuff was first introduced. There are two test cases: 'crtest.exe' is an
app that imports a DLL with complex data structures and accesses members
of those structs.  crtest1.exe is an app that imports a DLL -- and THAT
DLL imports a second DLL with complex data structures; the first DLL
then accesses members of those structs in the second DLL.

Also attached:  Kai's most recent pseudo-reloc.c patch, with the "slight
reversion" mentioned in [3] below and the public domain disclosure restored.

I used ld.exe built from today's CVS (includes Kai's most recent
changes). I can make that available, but it'll take me a while to
produce the proper src package so as to abide by GPL.

Tests performed under cygwin-1.7, Vista, as a non-Administrators-group user.

--
Chuck

[1] Original (existing cygwin) test-app, test-dll with -v1 relocs. These
are the expected results.
$ ./crtest
child: data=1 1
parent: data=1 23 e
$ ./crtest1
child: data=1 23 e
parent: data=1 23 e

[2] With Kai's change, and most recent ld.exe (20080126) with -v1 relocs
$ ./crtest
child: data=1 1
parent: data=1 23 e
$ ./crtest1
      3 [main] crtest1 6040 child_copy: linked dll data write copy
failed, 0x242000..0x242040, done 0, windows pid 5556, Win32 error 487
fork: Resource temporarily unavailable

[3] Modify -v1 handling in pseudo-reloc.c to directly rewrite the reloc,
rather than using __write_memory)
$ ./crtest
child: data=1 1
parent: data=1 23 e
$ ./crtest1
child: data=1 23 e
parent: data=1 23 e

[4] Using pseudo-reloc code as in [2] OR [3], but with -v2 relocs
$ ./crtest
child: data=268443648 1628191118 ±
parent: data=1 23 e
$ ./crtest1
      3 [main] crtest1 3080 child_copy: linked dll data write copy
failed, 0x842000..0x842040, done 0, windows pid 2308, Win32 error 87
fork: Resource temporarily unavailable


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pseudo-reloc.patch
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20090126/8681e804/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pseudo-reloc-tests.tar.bz2
Type: application/octet-stream
Size: 1729 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20090126/8681e804/attachment.obj>


More information about the Cygwin-developers mailing list