Re: [PATCH] New --pe-dll-characteristcs switch for PE ld.

["Charles Wilson" <cygwin at cwilson dot fastmail dot fm>]

Christopher Faylor wrote:
> I would like to see an objcopy option at some point.  I don't agree with
> the prevailing cygwin opinion that you need a separate binary to deal
> with this.  It seems silly to have objcopy able to do only some things
> to a PE and, if objcopy can do this, then I don't see why you need an
> extra program to manipulate this field.

I agree that objcopy should be able to manipulate this (these) field(s).
However, having a simple tool that does a simple thing is The Unix Way.
Having a giant do-everything tool is...not.  For that we have Perl. <g>

[The following gets OT for binutils; I've CC:ed the cygwin list. If you
wish to continue this subthread, please take it over there]
Seriously, with regards to cygwin though, there are a few important
reasons for the bit-twiddler program to be separate from  objcopy, even
if it duplicates some of its functionality.

1) we're going to recommend that -- until everything in the cygwin
distro is rebuilt using a not-yet-available ld with new defaults --
users (including lusers and n00bs) -- run a bit-twiddler tool on many,
if not all, of the DLLs and EXEs in their installation. It would be bad
if this tool was developer-centric, with lots of confusing (to the
uninitiated) options that have the potential to seriously foul up the
target object(s) in unrecoverable ways, if used incorrectly.  Like
objcopy.  The bit-twiddler proggie, being so simple and limited in
scope, can always revert any changes it makes. Even when used by a n00b.

2) Do we really want all users -- who might not be developers -- who
happen to run in to a particular problem be forced to download and
install all of binutils, just for objcopy?

3) We're dealing with an issue where EXEs will not operate at all if
they do not have the correct DllCharacteristics bits.  Which exes suffer
from this limitation is not immediately obvious, and we don't know what
triggers the misbehavior (on WindowsTS, at least). So far we are "lucky"
-- it appears that the binutils tools such as nm and objcopy are NOT
affected by this issue, but we don't know why, nor if our "luck" will
change in the future. In the end, we might be forced to distribute the
bit-twiddler as a mingw app, not a cygwin one. I don't think we (cygwin)
want to distribute a standalone version of i686-pc-mingw32-objcopy, nor
as in #2 above, force all users (who happen to run in to ...) to
download mingw-cross-binutils.

4) The behavior of a specific bit-twiddler program can be tweaked to
better suit our intended purpose: to be called on a large list of files
ONCE to perform similar operations on all of those files, thus avoiding
lots of forks.  This is important not just for speed, but also because
the dynbase issue is the solution to a problem that fails specifically
when you're doing a lot of forks. (Granted, you could avoid this latter
issue by ensuring that the bit-twiddler program -- be it objdump or
peflags -- itself is only shipped with the dynbase flag preset). But
AFAIK objdump is not meant to operate in a "SIMD" manner -- that is, do
the same operation on an entire list of target objects. Rather, objcopy
takes exactly two file names: one input and one optional output.  If the
output file isn't specified, then the temporary modified version is
renamed over the input (which is the behavior we'd want to exploit for a
make-all-dynbase script -- or we'd do the rename manually IN that
script, having given objcopy an explicit temporary name for its output).
 That's a lot of extra disk writes and data copying -- again, slow. 
peflags operates inplace.

5) Why does cygwin ship rebase? Technically objcopy could and should do
this, too (even though that particular operation is a lot more
complicated than just setting a value in the PE file's header). But #1
thru #4 above all also apply with regards to rebase.exe, even if objcopy
had that capability.

--
Chuck

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