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/
