This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


[oops. I replied to a non-existent list, so binutils never saw this and
cygwin will see it twice. Sorry about that]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]