public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* [1.7] rebaseall doesn't solve the problem
@ 2009-02-21  2:27 Charles Wilson
  2009-02-24 10:06 ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-02-21  2:27 UTC (permalink / raw)
  To: Cygwin Mailing List

For the last several days I have been having a terrible time with the old

      2 [main] perl 3620 C:\cygwin-1.7\bin\perl.exe: *** fatal error -
unable to remap
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll to same
address as parent(0x860000) != 0x14E0000
      5 [main] perl 3636 child_info::sync: wait failed, pid 3620, Win32
error 183
    418 [main] perl 3636 fork: child 3620 - died waiting for dll
loading, errno 11


issue.  It's being triggered when running the autotools (so the libtool
testsuite is a nightmare, as is trying to package anything using cygport
for 1.7) -- and the culprit is ALWAYS Cwd.dll. I've tried rebasing to
various addresses (0x70000000, 0x68000000, 0x6500000) but to no avail.

Using process explorer, I find that for SOME reason, even in the parent
perl, the Cwd.dll (one of the DLLs shipped with perl, in
/usr/lib/perl5/5.10/i686-pc-cygwin/auto/Cwd/Cwd.dll) is being loaded in
a strange location:

Image Base: 0x5d6a0000
Location in Parent: 0x00860000
Location in Child : 0x014E0000

I can't see that there is any conflict at the image base location of
0x5d6a0000, so I'm not sure why, in the parent, Cwd.dll was loaded that
low.  However, the low memory region is rife with conflict, and in fact,
in the child:

C:\Windows\system32\locale.nls
image base: 0x0
mapped location: 0x00960000
mapped size:     0x0037F000

which means that locale.nls extends all the way down to 0x005E1000, so
Cwd.dll can't go at 0x00860000.

Rebasing won't solve this problem, because Cwd.dll is NOT being loaded
at the rebased (0x5d6a0000) location even tho, as far as I can tell,
there is no conflict there. Instead, it's being loaded at a traffic
heavy location for no good reason that I can see -- and I keep getting
hit by passing cars.

Help?

--
Chuck

PS. The full output of sysinternal's listdll for the parent (first) and
child (second) is below. But first: in the parent, there are three items
that have an image base of 0x0, so they are "relocated", in addition to
Cwd.dll:

name         mapped to   mapped size   image base
locale.nls   0x19990000  0x0037f000    0x0
locale.nls   0x00a10000  0x0037f000    0x0
oleaccrc.dll 0x008d0000  0x00001000    0x0
Cwd.dll      0x00860000  0x00008000    0x5d6a0000

In the (partially loaded) child, there is as yet only one copy of
locale.nls loaded, and the Cwd.dll that are relocated from their actual
image base:

name         mapped to   mapped size   image base
locale.nls   0x00960000  0x0037f000    0x0
Cwd.dll      0x014e0000  0x00008000    0x5d6a0000

In each case, all of the other dlls are loaded at their actual image
base and are not relocated.



ListDLLs v2.25 - DLL lister for Win9x/NT
Copyright (C) 1997-2004 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
perl.exe pid: 4948
Command line: C:\cygwin-1.7\bin\perl.exe -w /usr/bin/autom4te-2.63
--language=m4sh -B libltdl/config libltdl/config/ltmain.m4sh

  Base        Size      Version	        Path
  0x52060000  0x8000                    C:\cygwin-1.7\bin\perl.exe
  0x77a80000  0x127000  6.00.6001.18000  C:\Windows\system32\ntdll.dll
  0x763a0000  0xdb000   6.00.6001.18000  C:\Windows\system32\kernel32.dll
  0x61000000  0x300000  1007.00.0000.0000  C:\cygwin-1.7\bin\cygwin1.dll
  0x76c10000  0xc6000   6.00.6001.18000  C:\Windows\system32\ADVAPI32.DLL
  0x76ab0000  0xc2000   6.00.6001.18051  C:\Windows\system32\RPCRT4.dll
  0x5d760000  0x184000                  C:\cygwin-1.7\bin\cygperl5_10.dll
  0x64ed0000  0x7000                    C:\cygwin-1.7\bin\cygcrypt-0.dll
  0x75630000  0x3b000   6.00.6001.18000  C:\Windows\system32\rsaenh.dll
  0x77c10000  0xaa000   7.00.6001.18000  C:\Windows\system32\msvcrt.dll
  0x5d680000  0xd000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Data\Dumper\Dumper.dll
  0x5d050000  0x9000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\IO\IO.dll
  0x5d130000  0x7000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Fcntl\Fcntl.dll
  0x5cee0000  0x1c000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\POSIX\POSIX.dll
  0x00860000  0x8000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll
  0x76130000  0x2c000   6.00.6001.18000  C:\Windows\system32\apphelp.dll
  0x73fd0000  0x32000   6.00.6001.18000  C:\Windows\system32\winmm.dll
  0x76300000  0x9d000   6.00.6001.18000  C:\Windows\system32\USER32.dll
  0x76780000  0x4b000   6.00.6001.18159  C:\Windows\system32\GDI32.dll
  0x76480000  0x144000  6.00.6001.18000  C:\Windows\system32\ole32.dll
  0x767d0000  0x8d000   6.00.6001.18000  C:\Windows\system32\OLEAUT32.dll
  0x74680000  0x39000   4.02.5406.0000  C:\Windows\system32\OLEACC.dll
  0x76760000  0x1e000   6.00.6001.18000  C:\Windows\system32\IMM32.DLL
  0x76d10000  0xc8000   6.00.6001.18000  C:\Windows\system32\MSCTF.dll
  0x77cd0000  0x9000    6.00.6001.18000  C:\Windows\system32\LPK.DLL
  0x768e0000  0x7d000   1.626.6001.18000  C:\Windows\system32\USP10.dll
  0x6c1b0000  0x5000    8.00.0000.0223  C:\Windows\system32\avgrsstx.dll
------------------------------------------------------------------------------
perl.exe pid: 3620
Command line: C:\cygwin-1.7\bin\perl.exe

  Base        Size      Version	        Path
  0x52060000  0x8000                    C:\cygwin-1.7\bin\perl.exe
  0x77a80000  0x127000  6.00.6001.18000  C:\Windows\system32\ntdll.dll
  0x763a0000  0xdb000   6.00.6001.18000  C:\Windows\system32\kernel32.dll
  0x61000000  0x300000  1007.00.0000.0000  C:\cygwin-1.7\bin\cygwin1.dll
  0x76c10000  0xc6000   6.00.6001.18000  C:\Windows\system32\ADVAPI32.DLL
  0x76ab0000  0xc2000   6.00.6001.18051  C:\Windows\system32\RPCRT4.dll
  0x5d760000  0x184000                  C:\cygwin-1.7\bin\cygperl5_10.dll
  0x64ed0000  0x7000                    C:\cygwin-1.7\bin\cygcrypt-0.dll
  0x5d680000  0xd000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Data\Dumper\Dumper.dll
  0x5d050000  0x9000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\IO\IO.dll
  0x5d130000  0x7000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Fcntl\Fcntl.dll
  0x5cee0000  0x1c000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\POSIX\POSIX.dll
  0x014e0000  0x8000
C:\cygwin-1.7\lib\perl5\5.10\i686-cygwin\auto\Cwd\Cwd.dll



--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-21  2:27 [1.7] rebaseall doesn't solve the problem Charles Wilson
@ 2009-02-24 10:06 ` Corinna Vinschen
  2009-02-27 21:22   ` Charles Wilson
  0 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-02-24 10:06 UTC (permalink / raw)
  To: cygwin

On Feb 20 21:27, Charles Wilson wrote:
> Using process explorer, I find that for SOME reason, even in the parent
> perl, the Cwd.dll (one of the DLLs shipped with perl, in
> /usr/lib/perl5/5.10/i686-pc-cygwin/auto/Cwd/Cwd.dll) is being loaded in
> a strange location:
> 
> Image Base: 0x5d6a0000
> Location in Parent: 0x00860000
> Location in Child : 0x014E0000
> 
> I can't see that there is any conflict at the image base location of
> 0x5d6a0000, so I'm not sure why, in the parent, Cwd.dll was loaded that
> low.  However, the low memory region is rife with conflict, and in fact,
> in the child:
> 
> C:\Windows\system32\locale.nls
> image base: 0x0
> mapped location: 0x00960000
> mapped size:     0x0037F000
> 
> which means that locale.nls extends all the way down to 0x005E1000, so
> Cwd.dll can't go at 0x00860000.

Hm?  Isn't that end_of_mapped_region = mapped_location + mapped_size?

> Rebasing won't solve this problem, because Cwd.dll is NOT being loaded
> at the rebased (0x5d6a0000) location even tho, as far as I can tell,
> there is no conflict there. Instead, it's being loaded at a traffic
> heavy location for no good reason that I can see -- and I keep getting
> hit by passing cars.
> 
> Help?

I'm wondering if that's a result of ASLR in Vista.  The document
http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf describes,
starting at page 11, a registry key to influence Vista's ASLR behaviour.
Does that change the behaviour for you?

If so, there's nothing Cygwin can do against that.  In the long run,
only a native fork() implementation would help.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-24 10:06 ` Corinna Vinschen
@ 2009-02-27 21:22   ` Charles Wilson
  2009-02-28 10:43     ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-02-27 21:22 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 3268 bytes --]

Corinna Vinschen wrote:
>> which means that locale.nls extends all the way down to 0x005E1000, so
>> Cwd.dll can't go at 0x00860000.
> 
> Hm?  Isn't that end_of_mapped_region = mapped_location + mapped_size?

You're right. I was confused by the upside-down chart I was looking at.

> I'm wondering if that's a result of ASLR in Vista.  The document
> http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf describes,
> starting at page 11, a registry key to influence Vista's ASLR behaviour.
> Does that change the behaviour for you?

It *changes* the behavior, but doesn't fix it.

the default case is key not present, or key present and equal to
anything other than 0 or -1/0xffffffff. In this case, only those DLLs
explicitly marked ASLR-compatible are supposed to be relocated --
subject to the other normal relocation rules.

with the registry key set to 0 (disable ASLR, even if the DLL says it is
ASLR-compatible), I get the same behavior as before: can't remap Cwd.dll.

with the registry key set to -1/0xffffffff (force ASLR for all DLLs), I
get slightly different behavior: can't allocate stack. Presumably this
is because cygwin1.dll itself falls victim to relocation in this
situation (verified this by looking at cygwin1.dll's load address).

> If so, there's nothing Cygwin can do against that.  In the long run,
> only a native fork() implementation would help.

Well, maybe not! From the document you referenced:

    Since Windows relies on relocations instead of position
    independent code, a DLL must be loaded at the same address
    in each process that uses it to allow the physical memory
    used by the DLL to be shared. To facilitate this behaviour,
    a global bitmap called _MiImageBitMap is used to represent
    the address space from 0x50000000 to 0x78000000. The bitmap
    is 0x2800 bits in length with each bit representing 64KB
    of memory. As each DLL is loaded, its position is recorded
    by setting the appropriate bits in the bitmap to mark the
    memory where the DLL is being mapped. When the same DLL
    is loaded in another process, its section object is reused
    and it is mapped at the same virtual addresses.

So, by marking a particular (or all but cygwin1.dll?) DLL as
ASLR-compatibile, we may be able to coerce the Windows runtime loader
into ensuring that the DLLs are loaded at the same memory location for
all concurrent processes (unless the parent has filled up the space from
0x50000000 to 0x78000000, and so is forced to put an ASLR-compatible DLL
somewhere else that is not tracked by _MiImageBitMap).


I wrote a little utility to explicitly mark a DLL as ASLR-compatible.
Using it on Cwd.dll -- the offending one in my situation -- I was able
to eliminate the problem!

I've created it as a patch to the rebase package: 'aslr.exe' is a
separate utility and doesn't actually use the imagebase library.  I've
also modified rebaseall to optionally call it after rebase.  It seems to
work okay; I've manually used it on a dozen or so DLLs -- but I'm still
a little nervous about running it on EVERYTHING in my installation,
since it doesn't quite have the history behind it that rebase does.

Another pair of eyes (or dozen) looking at the code would be nice...

Patch attached. Jason?

--
Chuck

[-- Attachment #2: rebase-2.4.4-1.aslr.patch --]
[-- Type: application/x-patch, Size: 20601 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-27 21:22   ` Charles Wilson
@ 2009-02-28 10:43     ` Corinna Vinschen
  2009-02-28 18:50       ` Charles Wilson
  0 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-02-28 10:43 UTC (permalink / raw)
  To: cygwin

On Feb 27 16:21, Charles Wilson wrote:
> Corinna Vinschen wrote:
> [...]
> > I'm wondering if that's a result of ASLR in Vista.  The document
> > http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf [...]
> [...]
> > If so, there's nothing Cygwin can do against that.  In the long run,
> > only a native fork() implementation would help.
> 
> Well, maybe not! From the document you referenced:
> 
>     Since Windows relies on relocations instead of position
>     independent code, a DLL must be loaded at the same address
>     in each process that uses it to allow the physical memory
>     used by the DLL to be shared. To facilitate this behaviour,
>     a global bitmap called _MiImageBitMap is used to represent
>     the address space from 0x50000000 to 0x78000000. The bitmap
>     is 0x2800 bits in length with each bit representing 64KB
>     of memory. As each DLL is loaded, its position is recorded
>     by setting the appropriate bits in the bitmap to mark the
>     memory where the DLL is being mapped. When the same DLL
>     is loaded in another process, its section object is reused
>     and it is mapped at the same virtual addresses.
> 
> So, by marking a particular (or all but cygwin1.dll?) DLL as
> ASLR-compatibile, we may be able to coerce the Windows runtime loader
> into ensuring that the DLLs are loaded at the same memory location for
> all concurrent processes (unless the parent has filled up the space from
> 0x50000000 to 0x78000000, and so is forced to put an ASLR-compatible DLL
> somewhere else that is not tracked by _MiImageBitMap).
> 
> I wrote a little utility to explicitly mark a DLL as ASLR-compatible.
> Using it on Cwd.dll -- the offending one in my situation -- I was able
> to eliminate the problem!

Way cool, Chuck.  Especially the fact that this tool can also mark
executables with the TS-aware flag (doesn't make sense for DLLs, afaik).
This helps to test if setting this flag in Cygwin binaries will
allow Cygwin to run on 2008 with TS without disabling DEP.

If so, I'm wondering if setting the TS-aware flag shouldn't become
default in GCC.  What do you say, Dave?  Would that be possible?

That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
All newly built binaries would have the flag set already, and older
binaries could be tweaked with the aslr utility.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 10:43     ` Corinna Vinschen
@ 2009-02-28 18:50       ` Charles Wilson
  2009-02-28 19:34         ` Matt Wozniski
                           ` (2 more replies)
  0 siblings, 3 replies; 43+ messages in thread
From: Charles Wilson @ 2009-02-28 18:50 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:

> Way cool, Chuck.  Especially the fact that this tool can also mark
> executables with the TS-aware flag (doesn't make sense for DLLs, afaik).
> This helps to test if setting this flag in Cygwin binaries will
> allow Cygwin to run on 2008 with TS without disabling DEP.

Well, the tool would need a little tweaking I think. Right now it skips
any image (DLL or exe) that does not contain relocations.

> If so, I'm wondering if setting the TS-aware flag shouldn't become
> default in GCC.  What do you say, Dave?  Would that be possible?

I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2),
so we can get aslr integerated into rebase, and the rebaseall changes
tested.  Should I also add a switch to rebaseall that means: ONLY alsr,
NO rebasing.  There's already a flag that allows you to add .exe's to
the "rebase" list -- but you can't remove dll's and .so's from the list.

Maybe the aslr functionality is different enough -- and useful in enough
contexts that differ from rebasing -- that instead of incorporating
'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script?

> That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
> All newly built binaries would have the flag set already, and older
> binaries could be tweaked with the aslr utility.

That would be nice.  However, ONLY exe's linked with cygwin1.dll should
be marked this way, right?  Not cygcheck, strace, and whatever other few
exes we might find in the cygwin installation lists.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 18:50       ` Charles Wilson
@ 2009-02-28 19:34         ` Matt Wozniski
  2009-02-28 19:51         ` Christopher Faylor
  2009-02-28 20:16         ` Corinna Vinschen
  2 siblings, 0 replies; 43+ messages in thread
From: Matt Wozniski @ 2009-02-28 19:34 UTC (permalink / raw)
  To: cygwin

On 2/28/09, Charles Wilson wrote:
>  Maybe the aslr functionality is different enough -- and useful in enough
>  contexts that differ from rebasing -- that instead of incorporating
>  'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script?

+1 for that suggestion.  It's doing something completely different.
It will only work on systems with ASLR, which IIUC excludes XP SP1 and
2000.  Even where it will work, rebasing might still be required if
there are too many DLLs for _MiImageBitMap to track them all.  Where
it does work completely, the rebasing part of rebaseall should be
unneeded, right?  All of that seems to speak to a desire to have it
available as a separate script, though maybe having a flag for
rebaseall to call that script would be useful.

Hope I didn't misunderstand any of this discussion...  :-)

~Matt

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 18:50       ` Charles Wilson
  2009-02-28 19:34         ` Matt Wozniski
@ 2009-02-28 19:51         ` Christopher Faylor
  2009-02-28 20:04           ` Charles Wilson
  2009-02-28 20:29           ` Corinna Vinschen
  2009-02-28 20:16         ` Corinna Vinschen
  2 siblings, 2 replies; 43+ messages in thread
From: Christopher Faylor @ 2009-02-28 19:51 UTC (permalink / raw)
  To: cygwin

On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote:
>Corinna Vinschen wrote:
>
>> Way cool, Chuck.  Especially the fact that this tool can also mark
>> executables with the TS-aware flag (doesn't make sense for DLLs, afaik).
>> This helps to test if setting this flag in Cygwin binaries will
>> allow Cygwin to run on 2008 with TS without disabling DEP.
>
>Well, the tool would need a little tweaking I think. Right now it skips
>any image (DLL or exe) that does not contain relocations.
>
>> If so, I'm wondering if setting the TS-aware flag shouldn't become
>> default in GCC.  What do you say, Dave?  Would that be possible?
>
>I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2),
>so we can get aslr integerated into rebase, and the rebaseall changes
>tested.  Should I also add a switch to rebaseall that means: ONLY alsr,
>NO rebasing.  There's already a flag that allows you to add .exe's to
>the "rebase" list -- but you can't remove dll's and .so's from the list.
>
>Maybe the aslr functionality is different enough -- and useful in enough
>contexts that differ from rebasing -- that instead of incorporating
>'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script?

It should be trivial to add this to binutils.  Doesn't it ultimately
belong in ld and (maybe) objcopy?

I can add this now but I don't think it should be the default just yet.

>> That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
>> All newly built binaries would have the flag set already, and older
>> binaries could be tweaked with the aslr utility.
>
>That would be nice.  However, ONLY exe's linked with cygwin1.dll should
>be marked this way, right?  Not cygcheck, strace, and whatever other few
>exes we might find in the cygwin installation lists.

Do the exes themselves need this bit as well as the dlls?

cgf

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 19:51         ` Christopher Faylor
@ 2009-02-28 20:04           ` Charles Wilson
  2009-02-28 20:29           ` Corinna Vinschen
  1 sibling, 0 replies; 43+ messages in thread
From: Charles Wilson @ 2009-02-28 20:04 UTC (permalink / raw)
  To: cygwin

Christopher Faylor wrote:
> It should be trivial to add this to binutils.  Doesn't it ultimately
> belong in ld and (maybe) objcopy?

Well, I'm sure it would be useful there.  However, just as ld can create
a DLL with a user-specified image base, yet we still have a separate
special purpose utility for rebasing them, it makes sense that ld can
create an exe or dll with a specific pe_dll_characteristics flag, but a
separate single-purpose utility to modify it is also useful.

I really don't want Q. Random User to try and run objcopy <confusing
options> on his entire installation...

> I can add this now but I don't think it should be the default just yet.

Agree.

BTW, this was mentioned on the binutils list about two years ago, but
nothing ever came of it:
http://sourceware.org/ml/binutils/2007-02/msg00046.html

> Do the exes themselves need this bit as well as the dlls?

From what I understand, ASLR makes sense for both DLLs and EXEs -- but
only if the image has relocations (most DLLs, and PIE exectuables).
TS-Aware makes sense only for EXEs according to Corinna.  NX could be
applied to any DLL or EXE (I think).

My mistake in the existing alsr code was to always skip if no
relocations -- so since we don't have PIE exes, you can't currently set
the TS or NX flags on ordinary exes with the tool.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 18:50       ` Charles Wilson
  2009-02-28 19:34         ` Matt Wozniski
  2009-02-28 19:51         ` Christopher Faylor
@ 2009-02-28 20:16         ` Corinna Vinschen
  2009-02-28 21:19           ` Charles Wilson
  2 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-02-28 20:16 UTC (permalink / raw)
  To: cygwin

On Feb 28 13:47, Charles Wilson wrote:
> Corinna Vinschen wrote:
> 
> > Way cool, Chuck.  Especially the fact that this tool can also mark
> > executables with the TS-aware flag (doesn't make sense for DLLs, afaik).
> > This helps to test if setting this flag in Cygwin binaries will
> > allow Cygwin to run on 2008 with TS without disabling DEP.
> 
> Well, the tool would need a little tweaking I think. Right now it skips
> any image (DLL or exe) that does not contain relocations.

Uh, ok.  In that case, yes, it needs some tweaking.  Actually, maybe
the tool should really be named differently.  Something suggesting
that it in general changes Win32-related PE/COFF header flags.  ASLR
and TS-aware are just some of them, in theory.

> > If so, I'm wondering if setting the TS-aware flag shouldn't become
> > default in GCC.  What do you say, Dave?  Would that be possible?
> 
> I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2),
> so we can get aslr integerated into rebase, and the rebaseall changes
> tested.  

Yes, sure.  I have to test if the TS-aware flag makes any difference on
a 2K8 TS machine anyway.  I think (and hope) that this flag will
persuade tsappcmp.dll into igoring an executable instead of scrambling
its page executable protection flags.  If so, we should really set this
flag in all applications.  Well, not that I gave up the idea that
Microsoft should fix that bug in tsappcmp.dll in the first place...

> Should I also add a switch to rebaseall that means: ONLY alsr,
> NO rebasing.  There's already a flag that allows you to add .exe's to
> the "rebase" list -- but you can't remove dll's and .so's from the list.

Makes sense to me.

> > That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
> > All newly built binaries would have the flag set already, and older
> > binaries could be tweaked with the aslr utility.
> 
> That would be nice.  However, ONLY exe's linked with cygwin1.dll should
> be marked this way, right?  Not cygcheck, strace, and whatever other few
> exes we might find in the cygwin installation lists.

Hmm, I'm not sure about that one.  At least only EXEs should be marked
TS-aware automatically.  The flag has no meaning on DLLs, afaik.
*Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big
help in all cases.  Cygwin applications are TS-aware by default anyway.
If somebody actually manages to write a non-TS-aware Cygwin application,
I'd say this guy should reset the TS-aware flag manually.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 19:51         ` Christopher Faylor
  2009-02-28 20:04           ` Charles Wilson
@ 2009-02-28 20:29           ` Corinna Vinschen
  2009-02-28 21:30             ` Charles Wilson
  2009-03-02 12:08             ` Corinna Vinschen
  1 sibling, 2 replies; 43+ messages in thread
From: Corinna Vinschen @ 2009-02-28 20:29 UTC (permalink / raw)
  To: cygwin

On Feb 28 14:51, Christopher Faylor wrote:
> On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote:
> >Corinna Vinschen wrote:
> >> If so, I'm wondering if setting the TS-aware flag shouldn't become
> >> default in GCC.  What do you say, Dave?  Would that be possible?
> >
> >I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2),
> >[...]
> >Maybe the aslr functionality is different enough -- and useful in enough
> >contexts that differ from rebasing -- that instead of incorporating
> >'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script?
> 
> It should be trivial to add this to binutils.  Doesn't it ultimately
> belong in ld and (maybe) objcopy?

Yes, that should be done in ld.

> I can add this now but I don't think it should be the default just yet.

If the TS-aware flag actually helps to avoid the tsappcmp.dll bug, then
I think the flag should be set by ld by default for Cygwin apps.

> >That would be nice.  However, ONLY exe's linked with cygwin1.dll should
> >be marked this way, right?  Not cygcheck, strace, and whatever other few
> >exes we might find in the cygwin installation lists.
> 
> Do the exes themselves need this bit as well as the dlls?

Only exes require the TS-aware bit.  Two interesting snippets from MSDN:

http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx
http://msdn.microsoft.com/en-us/library/01cfys9z.aspx

The first one actually explains that the overhead of loading a
compatibility DLL can be avoided by using the TS-aware flag.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 20:16         ` Corinna Vinschen
@ 2009-02-28 21:19           ` Charles Wilson
  2009-03-01 10:20             ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-02-28 21:19 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:
> Uh, ok.  In that case, yes, it needs some tweaking.  Actually, maybe
> the tool should really be named differently.  Something suggesting
> that it in general changes Win32-related PE/COFF header flags.  ASLR
> and TS-aware are just some of them, in theory.

I'm open to suggestions.  "peimgflags"?  Currently, aslr only
manipulates the OPT_IMG_HEADER:DllCharacteristics field (which is a
misnomer, because some of the values apply to exe's).

We might also want to be able to set IMAGE_FILE_AGGRESIVE_WS_TRIM in the
IMAGE_FILE_HEADER:Characteristics field for things like sshd.



As currently coded, it *appears* that neither rebase nor aslr adapt to
the (slightly different) 64bit pe format.  Actually, I think only rebase
is affected by this, because the variations in the format occur past the
OPT_IMG_HEADER:DllCharacteristics offset.

I don't have a 64 bit machine to test on, so I'll have to pass on
"fixing" the imagehelper library used by rebase...

The differences are minor; larger field sizes for some values (and
therefore different field offsets for values past them). Just compare
and contrast IMAGE_OPTIONAL_HEADER32 and IMAGE_OPTIONAL_HEADER64 in
w32api/winnt.h.  From dlltool:

/*  & NumberOfRvaAndSizes.  */
#ifdef pe_use_x86_64
  num_entries = pe_get32 (dll, opthdr_ofs + 92 + 4 * 4);
#else
  num_entries = pe_get32 (dll, opthdr_ofs + 92);
#endif

#ifdef pe_use_x86_64
  export_rva  = pe_get32 (dll, opthdr_ofs + 96 + 4 * 4);
  export_size = pe_get32 (dll, opthdr_ofs + 100 + 4 * 4);
#else
  export_rva = pe_get32 (dll, opthdr_ofs + 96);
  export_size = pe_get32 (dll, opthdr_ofs + 100);
#endif

but I don't think #ifdefs are the way to go. We want to be able to
manipulate 64bit images on a 32bit machine, and vice versa -- based on
the value of the IMAGE_FILE_HEADER:Machine field.

IMAGE_FILE_MACHINE_I386		0x014c	x86
IMAGE_FILE_MACHINE_IA64		0x0200	Itanium
IMAGE_FILE_MACHINE_AMD64	0x8664	x64

Then again, maybe this isn't all that important, as the only 64-bit
image we have is cyglsa64.dll -- and my patch to rebaseall forces it to
skip that one anyway. Everything else in the cygwin distro is strictly
32 bits.

> I have to test if the TS-aware flag makes any difference on
> a 2K8 TS machine anyway.  I think (and hope) that this flag will
> persuade tsappcmp.dll into igoring an executable instead of scrambling
> its page executable protection flags.  If so, we should really set this
> flag in all applications.  Well, not that I gave up the idea that
> Microsoft should fix that bug in tsappcmp.dll in the first place...

Ha!

>> Should I also add a switch to rebaseall that means: ONLY alsr,
>> NO rebasing.  There's already a flag that allows you to add .exe's to
>> the "rebase" list -- but you can't remove dll's and .so's from the list.
> 
> Makes sense to me.

Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
 of code with rebaseall, but it's not really all THAT big a script.  The
reason I didn't do that originally was I wanted to reuse the same
(generated) filelist in each case.  But, it seems that the flexibility
in having aslrall(?) make its own file list -- which may include exe's
as well as dll's -- is more important.

>>> That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
>>> All newly built binaries would have the flag set already, and older
>>> binaries could be tweaked with the aslr utility.
>> That would be nice.  However, ONLY exe's linked with cygwin1.dll should
>> be marked this way, right?  Not cygcheck, strace, and whatever other few
>> exes we might find in the cygwin installation lists.
> 
> Hmm, I'm not sure about that one.  At least only EXEs should be marked
> TS-aware automatically.  The flag has no meaning on DLLs, afaik.
> *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big
> help in all cases.  Cygwin applications are TS-aware by default anyway.
> If somebody actually manages to write a non-TS-aware Cygwin application,
> I'd say this guy should reset the TS-aware flag manually.

Oh, ok.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 20:29           ` Corinna Vinschen
@ 2009-02-28 21:30             ` Charles Wilson
  2009-03-01  9:47               ` Corinna Vinschen
  2009-03-02 12:08             ` Corinna Vinschen
  1 sibling, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-02-28 21:30 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:
> 
> Only exes require the TS-aware bit.  Two interesting snippets from MSDN:
> 
> http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx

But in order to set this flag without problems cropping up, you must
satisfy:

* The application does not run as a system service (that is, LUID=System).

This probably isn't an issue for cygwin-1.7 and beyond, given the
changes in how services are installed. (Dang, I need to release an
updated csih...)

* The application does not write to the HKEY Local Machine registry hive
for user specific data or configuration.

Hmm.  regtool? /proc/registry?

Either way, you lose. If we go one way, then you can't use regtool or
/proc/registry to manipulate the virtualized registry entries, if you're
trying to fix something related to a non-TS (windows) app. If we go the
other way, then you can't use regtool or /proc/registry to manipulate
the "real" non-virtualized registry.

Ditto for virtualized vs. non-virtualized /Program\ Files, /Windows, etc.

THERE's the reason to keep an old cygwin-1.5 installation laying around! <g>

> http://msdn.microsoft.com/en-us/library/01cfys9z.aspx

"/TSAWARE is not valid for drivers, VxDs, or DLLs. "

Yep, need to fix aslr.exe to not do that.

Also, I think I might use aslr to set the flag on my copy of NotePad++.
I hate having to install the syntax colorizer plugins into both my and
admin's virtualized Program Files directory...for every update...

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 21:30             ` Charles Wilson
@ 2009-03-01  9:47               ` Corinna Vinschen
  2009-03-01 10:05                 ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-01  9:47 UTC (permalink / raw)
  To: cygwin

On Feb 28 16:30, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Only exes require the TS-aware bit.  Two interesting snippets from MSDN:
> > 
> > http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx
> 
> But in order to set this flag without problems cropping up, you must
> satisfy:
> 
> * The application does not run as a system service (that is, LUID=System).
> 
> This probably isn't an issue for cygwin-1.7 and beyond, given the
> changes in how services are installed. (Dang, I need to release an
> updated csih...)

I don't think you will get problems even if you're running a Cygwin
application as system service.  I don't know the exact reason for this
rule, but all the TS-aware rules usually have something to do with
"don't change anything which might break the same application running in
another user context."  These rules don't have POSIX applications in
mind.

> * The application does not write to the HKEY Local Machine registry hive
> for user specific data or configuration.
> 
> Hmm.  regtool? /proc/registry?

Hmm, regedit?

You're taking these rules too literally, imho.

> Either way, you lose. If we go one way, then you can't use regtool or
> /proc/registry to manipulate the virtualized registry entries, if you're
> trying to fix something related to a non-TS (windows) app. If we go the
> other way, then you can't use regtool or /proc/registry to manipulate
> the "real" non-virtualized registry.

Cygwin applications won't use the virtualized registry keys anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-01  9:47               ` Corinna Vinschen
@ 2009-03-01 10:05                 ` Corinna Vinschen
  0 siblings, 0 replies; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-01 10:05 UTC (permalink / raw)
  To: cygwin

On Mar  1 10:47, Corinna Vinschen wrote:
> On Feb 28 16:30, Charles Wilson wrote:
> > * The application does not write to the HKEY Local Machine registry hive
> > for user specific data or configuration.

Oh, btw., did you read the above closly?  "not write ... HKLM ... user
specific".  We don't do that.  We don't use HKLM for user specific
data or configuration.  Only for system-wide data or configuration.

> > Hmm.  regtool? /proc/registry?
> 
> Hmm, regedit?

Which is to say, you can't use that rule on tools which are designed
to manipulate the registry in general.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 21:19           ` Charles Wilson
@ 2009-03-01 10:20             ` Corinna Vinschen
  2009-03-02  3:52               ` Charles Wilson
                                 ` (2 more replies)
  0 siblings, 3 replies; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-01 10:20 UTC (permalink / raw)
  To: cygwin

On Feb 28 16:18, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Uh, ok.  In that case, yes, it needs some tweaking.  Actually, maybe
> > the tool should really be named differently.  Something suggesting
> > that it in general changes Win32-related PE/COFF header flags.  ASLR
> > and TS-aware are just some of them, in theory.
> 
> I'm open to suggestions.  "peimgflags"?  Currently, aslr only

peflags?

> > I have to test if the TS-aware flag makes any difference on
> > a 2K8 TS machine anyway.  I think (and hope) that this flag will
> > persuade tsappcmp.dll into igoring an executable instead of scrambling
> > its page executable protection flags.  If so, we should really set this
> > flag in all applications.  Well, not that I gave up the idea that
> > Microsoft should fix that bug in tsappcmp.dll in the first place...
> 
> Ha!

Can you tweak the tool so I can test that next week?

> Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
>  of code with rebaseall, but it's not really all THAT big a script.  The
> reason I didn't do that originally was I wanted to reuse the same
> (generated) filelist in each case.  But, it seems that the flexibility
> in having aslrall(?) make its own file list -- which may include exe's
> as well as dll's -- is more important.

+1

> >> That would be nice.  However, ONLY exe's linked with cygwin1.dll should
> >> be marked this way, right?  Not cygcheck, strace, and whatever other few
> >> exes we might find in the cygwin installation lists.
> > 
> > Hmm, I'm not sure about that one.  At least only EXEs should be marked
> > TS-aware automatically.  The flag has no meaning on DLLs, afaik.
> > *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big
> > help in all cases.  Cygwin applications are TS-aware by default anyway.
> > If somebody actually manages to write a non-TS-aware Cygwin application,
> > I'd say this guy should reset the TS-aware flag manually.

Something I forgot in my other reply from a few minutes ago:

Cygwin applications are POSIX applications which are by default
multiuser aware == TS-aware since they are written for such an
environment.  Should an application *prove* to make trouble in a
TS-environment (minus the tsappcmp.dll bug) then we should try to find
out why.  In that case, especially if it's a plain POSIX tool, it might
be a bug in Cygwin itself.  Other than that, Cygwin and Cygwin apps are
designed to interact cleanly in a multiuser environment.  It should not
matter under which account they are running, even SYSTEM.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-01 10:20             ` Corinna Vinschen
@ 2009-03-02  3:52               ` Charles Wilson
  2009-03-04  6:00               ` Charles Wilson
  2009-03-10  0:30               ` [1.7] rebaseall doesn't solve the problem Matthew Woehlke
  2 siblings, 0 replies; 43+ messages in thread
From: Charles Wilson @ 2009-03-02  3:52 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:

>> I'm open to suggestions.  "peimgflags"?  Currently, aslr only
> 
> peflags?

Less typing is good.

> Can you tweak the tool so I can test that next week?

Yes, I've finished my current round of package rebuilding; I'll try to
get to peflags and peflags_all Monday PM.

>> Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
>> of code with rebaseall, but it's not really all THAT big a script.  The
>> reason I didn't do that originally was I wanted to reuse the same
>> (generated) filelist in each case.  But, it seems that the flexibility
>> in having aslrall(?) make its own file list -- which may include exe's
>> as well as dll's -- is more important.
> 
> +1

Ack.

> Cygwin applications are POSIX applications which are by default
> multiuser aware == TS-aware since they are written for such an
> environment.  Should an application *prove* to make trouble in a
> TS-environment (minus the tsappcmp.dll bug) then we should try to find
> out why.  In that case, especially if it's a plain POSIX tool, it might
> be a bug in Cygwin itself.  Other than that, Cygwin and Cygwin apps are
> designed to interact cleanly in a multiuser environment.  It should not
> matter under which account they are running, even SYSTEM.

Ack.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-02-28 20:29           ` Corinna Vinschen
  2009-02-28 21:30             ` Charles Wilson
@ 2009-03-02 12:08             ` Corinna Vinschen
  2009-03-02 15:14               ` Charles Wilson
  1 sibling, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-02 12:08 UTC (permalink / raw)
  To: cygwin

On Feb 28 21:28, Corinna Vinschen wrote:
> On Feb 28 14:51, Christopher Faylor wrote:
> > On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote:
> > >Corinna Vinschen wrote:
> > >> If so, I'm wondering if setting the TS-aware flag shouldn't become
> > >> default in GCC.  What do you say, Dave?  Would that be possible?
> > >
> > >I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2),
> > >[...]
> > >Maybe the aslr functionality is different enough -- and useful in enough
> > >contexts that differ from rebasing -- that instead of incorporating
> > >'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script?
> > 
> > It should be trivial to add this to binutils.  Doesn't it ultimately
> > belong in ld and (maybe) objcopy?
> 
> Yes, that should be done in ld.
> 
> > I can add this now but I don't think it should be the default just yet.
> 
> If the TS-aware flag actually helps to avoid the tsappcmp.dll bug, then
> I think the flag should be set by ld by default for Cygwin apps.

Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag
by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx

It would probably be very helpful in the long run if ld had some generic
option to set any of the Windows-specific header flags at build time.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-02 12:08             ` Corinna Vinschen
@ 2009-03-02 15:14               ` Charles Wilson
  2009-03-03  1:45                 ` Dave Korn
  0 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-03-02 15:14 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:
> Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag
> by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx
> 
> It would probably be very helpful in the long run if ld had some generic
> option to set any of the Windows-specific header flags at build time.

like perhaps a repeatable option

--peflags=[+-]tsaware|[+-]aslr|[+-]nx|[+-]wstrim

(note that not all of these flags affect the same field in the pe header).

or something even more generic but more powerful, WAY more dangerous,
and harder to use, like

--pehdrval=fieldname,hexval

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-02 15:14               ` Charles Wilson
@ 2009-03-03  1:45                 ` Dave Korn
  2009-03-03  2:06                   ` Charles Wilson
  2009-03-03  4:28                   ` Christopher Faylor
  0 siblings, 2 replies; 43+ messages in thread
From: Dave Korn @ 2009-03-03  1:45 UTC (permalink / raw)
  To: cygwin

Charles Wilson wrote:
> Corinna Vinschen wrote:
>> Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag
>> by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx
>>
>> It would probably be very helpful in the long run if ld had some generic
>> option to set any of the Windows-specific header flags at build time.
> 
> like perhaps a repeatable option

  Yep, this is exactly how I'm doing it.  Patch will be posted shortly.
Syntax looks like

  --pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]

e.g.

  --pe-dll-characteristics=0x0400|0x0100
  --pe-dll-characteristics=1+128+1024,noseh,nobind
  --pe-dll-characteristics noseh:nobind:tsaware

... etc ...

    cheers,
      DaveK


--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  1:45                 ` Dave Korn
@ 2009-03-03  2:06                   ` Charles Wilson
  2009-03-03  2:44                     ` Dave Korn
  2009-03-03  4:28                   ` Christopher Faylor
  1 sibling, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-03-03  2:06 UTC (permalink / raw)
  To: cygwin

Dave Korn wrote:
>   Yep, this is exactly how I'm doing it.  Patch will be posted shortly.
> Syntax looks like
> 
>   --pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]
> 
> e.g.
> 
>   --pe-dll-characteristics=0x0400|0x0100
>   --pe-dll-characteristics=1+128+1024,noseh,nobind
>   --pe-dll-characteristics noseh:nobind:tsaware

Nice. Where is the parsing done? I'm thinking of bringing in getopt_long
support into rebase and peflags (which is available for both cygwin and
mingw builds, just not MSVC. I don't think the rebase package cares
about that).

Anyway, if you've implemented that option parsing using just a small bit
of magic over top of getopt_long, I'll just borrow it (both packages are
GPL) and try to keep the interfaces for
	ld --pe-dll-characteristics
	peflags --dll-characteristics
sorta similar (with maybe some nice short synonyms for the common
peflags actions).  OTOH, if it relies on a bunch of pre-existing ld/*
glue, then...

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  2:06                   ` Charles Wilson
@ 2009-03-03  2:44                     ` Dave Korn
  2009-03-03 14:31                       ` Dave Korn
  0 siblings, 1 reply; 43+ messages in thread
From: Dave Korn @ 2009-03-03  2:44 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

Charles Wilson wrote:
> Dave Korn wrote:
>>   Yep, this is exactly how I'm doing it.  Patch will be posted shortly.
>> Syntax looks like
>>
>>   --pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]
>>
>> e.g.
>>
>>   --pe-dll-characteristics=0x0400|0x0100
>>   --pe-dll-characteristics=1+128+1024,noseh,nobind
>>   --pe-dll-characteristics noseh:nobind:tsaware
> 
> Nice. Where is the parsing done? 

  I added a variant of pe.em#set_pe_name() that can understand those sorts of
arguments, and a field in the definfo struct that allows to supply a list of
the abbreviated names and their corresponding values, so the mechanism is
nicely reusable.

> Anyway, if you've implemented that option parsing using just a small bit
> of magic over top of getopt_long, I'll just borrow it (both packages are
> GPL) and try to keep the interfaces for
> 	ld --pe-dll-characteristics
> 	peflags --dll-characteristics
> sorta similar 

  Yep, that would obviously be A Good Thing (TM).

> (with maybe some nice short synonyms for the common peflags actions).

  The mechanism is ready and waiting for you, just add the data tables!

> OTOH, if it relies on a bunch of pre-existing ld/* glue, then...

  Nope, should be easy to cut out the relevant bits, discarding ld-isms, and
paste the remainder into your code.  Copy of WIP attached for your
convenience; I've got to add doco and testcases before I can submit it, but
the parsing stuff is ready to fly and I'd appreciate any extra testing it gets :)

    cheers,
      DaveK


[-- Attachment #2: pe-dll-characteristics-patch.diff --]
[-- Type: text/plain, Size: 16642 bytes --]

? x.s
Index: include/coff/pe.h
===================================================================
RCS file: /cvs/src/src/include/coff/pe.h,v
retrieving revision 1.18
diff -p -u -r1.18 pe.h
--- include/coff/pe.h	4 Nov 2007 23:49:08 -0000	1.18
+++ include/coff/pe.h	3 Mar 2009 01:55:05 -0000
@@ -38,6 +38,17 @@
 #define IMAGE_FILE_UP_SYSTEM_ONLY            0x4000
 #define IMAGE_FILE_BYTES_REVERSED_HI         0x8000
 
+/* DllCharacteristics flag bits.  The inconsistent naming may seem
+   odd, but that is how they are defined in the PE specification.  */
+#define IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE          0x0040
+#define IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY       0x0080
+#define IMAGE_DLL_CHARACTERISTICS_NX_COMPAT             0x0100
+#define IMAGE_DLLCHARACTERISTICS_NO_ISOLATION           0x0200
+#define IMAGE_DLLCHARACTERISTICS_NO_SEH                 0x0400
+#define IMAGE_DLLCHARACTERISTICS_NO_BIND                0x0800
+#define IMAGE_DLLCHARACTERISTICS_WDM_DRIVER             0x2000
+#define IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE  0x8000
+
 /* Additional flags to be set for section headers to allow the NT loader to
    read and write to the section data (to replace the addresses of data in
    dlls for one thing); also to execute the section in .text's case.  */
Index: ld/NEWS
===================================================================
RCS file: /cvs/src/src/ld/NEWS,v
retrieving revision 1.97
diff -p -u -r1.97 NEWS
--- ld/NEWS	18 Feb 2009 18:23:07 -0000	1.97
+++ ld/NEWS	3 Mar 2009 01:55:06 -0000
@@ -1,5 +1,9 @@
 -*- text -*-
 
+* A new command-line flag '--pe-dll-characteristics' allows PE targets
+  to set the value of the PE file header's DllCharacteristics field,
+  using a flexible combination of numeric and symbolic names.
+
 * PE targets no longer make use of the long section names PE extension to
   the COFF format when generating executable images, by default.  The old
   (slightly non-conformant) behaviour can still be invoked by using the
Index: ld/emultempl/pe.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.145
diff -p -u -r1.145 pe.em
--- ld/emultempl/pe.em	27 Feb 2009 19:01:56 -0000	1.145
+++ ld/emultempl/pe.em	3 Mar 2009 01:55:06 -0000
@@ -229,6 +229,8 @@ fragment <<EOF
 					(OPTION_USE_NUL_PREFIXED_IMPORT_TABLES + 1)
 #define OPTION_DISABLE_LONG_SECTION_NAMES \
 					(OPTION_ENABLE_LONG_SECTION_NAMES + 1)
+#define OPTION_PE_DLL_CHARACTERISTICS \
+					(OPTION_DISABLE_LONG_SECTION_NAMES + 1)
 
 static void
 gld${EMULATION_NAME}_add_options
@@ -290,6 +292,7 @@ gld${EMULATION_NAME}_add_options
     {"large-address-aware", no_argument, NULL, OPTION_LARGE_ADDRESS_AWARE},
     {"enable-long-section-names", no_argument, NULL, OPTION_ENABLE_LONG_SECTION_NAMES},
     {"disable-long-section-names", no_argument, NULL, OPTION_DISABLE_LONG_SECTION_NAMES},
+    {"pe-dll-characteristics", required_argument, NULL, OPTION_PE_DLL_CHARACTERISTICS},
     {NULL, no_argument, NULL, 0}
   };
 
@@ -303,14 +306,47 @@ gld${EMULATION_NAME}_add_options
 
 typedef struct
 {
+  const char *name;
+  int len;
+  int value;
+} definfoflag;
+
+#define C(name)       { #name, sizeof(#name) - 1, name }
+#define CF(name,flag) { #name, sizeof(#name) - 1, flag }
+static const definfoflag dllchrctnames[] =
+{
+  /* Accept a few handy abbreviations.  */
+  CF(dynbase,     IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
+  CF(forceinteg,  IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
+  CF(nxcompat,    IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
+  CF(noisolation, IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
+  CF(noseh,       IMAGE_DLLCHARACTERISTICS_NO_SEH),
+  CF(nobind,      IMAGE_DLLCHARACTERISTICS_NO_BIND),
+  CF(wdmdriver,   IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
+  CF(tsaware,     IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
+  /* And the full names as defined in the PE specification.  */
+  C(IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
+  C(IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
+  C(IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
+  C(IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
+  C(IMAGE_DLLCHARACTERISTICS_NO_SEH),
+  C(IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
+  C(IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
+  { 0, 0, 0 },
+};
+
+typedef struct
+{
   void *ptr;
   int size;
   int value;
   char *symbol;
   int inited;
+  const definfoflag *flagnames;
 } definfo;
 
-#define D(field,symbol,def)  {&pe.field,sizeof(pe.field), def, symbol,0}
+#define D(field,symbol,def)         {&pe.field,sizeof(pe.field), def, symbol, 0, 0}
+#define DF(field,symbol,def,flags)  {&pe.field,sizeof(pe.field), def, symbol, 0, flags}
 
 static definfo init[] =
 {
@@ -318,7 +354,7 @@ static definfo init[] =
 #define IMAGEBASEOFF 0
   D(ImageBase,"__image_base__", NT_EXE_IMAGE_BASE),
 #define DLLOFF 1
-  {&dll, sizeof(dll), 0, "__dll__", 0},
+  {&dll, sizeof(dll), 0, "__dll__", 0, 0},
 #define MSIMAGEBASEOFF	2
   D(ImageBase, U ("__ImageBase"), NT_EXE_IMAGE_BASE),
   D(SectionAlignment,"__section_alignment__", PE_DEF_SECTION_ALIGNMENT),
@@ -339,10 +375,10 @@ static definfo init[] =
   D(SizeOfHeapReserve,"__size_of_heap_reserve__", 0x100000),
   D(SizeOfHeapCommit,"__size_of_heap_commit__", 0x1000),
   D(LoaderFlags,"__loader_flags__", 0x0),
-  { NULL, 0, 0, NULL, 0 }
+  DF(DllCharacteristics, "__dll_characteristics__", 0x0, dllchrctnames),
+  { NULL, 0, 0, NULL, 0, 0 }
 };
 
-
 static void
 gld_${EMULATION_NAME}_list_options (FILE *file)
 {
@@ -401,29 +437,50 @@ gld_${EMULATION_NAME}_list_options (FILE
                                        executable image files\n"));
   fprintf (file, _("  --disable-long-section-names       Never use long COFF section names, even\n\
                                        in object files\n"));
+  fprintf (file, _("  --pe-dll-characteristics mes       Never use long COFF section names, even\n\
+                                       an importlib, use <string><basename>.dll\n\
+                                       an importlib, use <string><basename>.dll\n\
+                                       an importlib, use <string><basename>.dll\n\
+                                       an importlib, use <string><basename>.dll\n"));
 }
 
+static const definfoflag *
+find_pe_flag_name (char *name, const definfoflag *flagnames)
+{
+  int i;
+
+  /* Look for the name, return pointer to definfoflag if found.  */
+  for (i = 0; flagnames[i].name; i++)
+    if (strncmp (name, flagnames[i].name, flagnames[i].len) == 0)
+      return &flagnames[i];
+  /* Unknown name could be an integer, so not an error here.  */
+  return 0;
+}
 
-static void
-set_pe_name (char *name, long val)
+static definfo *
+find_pe_name (char *name)
 {
   int i;
 
-  /* Find the name and set it.  */
+  /* Look for the name, return pointer to definfo.  */
   for (i = 0; init[i].ptr; i++)
-    {
-      if (strcmp (name, init[i].symbol) == 0)
-	{
-	  init[i].value = val;
-	  init[i].inited = 1;
-	  if (strcmp (name,"__image_base__") == 0)
-	    set_pe_name (U ("__ImageBase"), val);
-	  return;
-	}
-    }
+    if (strcmp (name, init[i].symbol) == 0)
+      return &init[i];
+  /* Unknown name is a serious internal coding error, so don't
+     bother to diagnose or return error indication, just bail.  */
   abort ();
 }
 
+static void
+set_pe_name (char *name, long val)
+{
+  /* Find the name and set it.  */
+  definfo *init = find_pe_name (name);
+  init->value = val;
+  init->inited = 1;
+  if (strcmp (name,"__image_base__") == 0)
+    set_pe_name (U ("__ImageBase"), val);
+}
 
 static void
 set_pe_subsystem (void)
@@ -543,6 +600,58 @@ set_pe_value (char *name)
   optarg = end;
 }
 
+static char
+is_flag_sep (char x)
+{
+  return x == '+' || x == '|' || x == ':' || x == ',';
+}
+
+static void
+set_pe_value_from_flags (char *name)
+{
+  long flags = 0;
+  definfo *init;
+
+  /* Look up the symbolic flag names.  Even if there aren't any we
+     will still parse multiple integers combined by separators.  */
+  init = find_pe_name (name);
+
+  /* Parse the flags out of optarg.  We accept any combination of
+     symbolic abbreviations and strtoul-parseable integers, separated
+     by any combination of '+', '|', ':' and ',' characters.  */
+  while (*optarg)
+    {
+      const definfoflag *flag;
+
+      /* Deliberately allow multiple conjoined separators.  */
+      while (is_flag_sep (*optarg))
+	optarg++;
+
+      flag = find_pe_flag_name (optarg, init->flagnames);
+      if (flag)
+	{
+	  flags |= flag->value;
+	  optarg += flag->len;
+	}
+      else
+	{
+	  char *end;
+	  long value;
+	  value = strtoul (optarg, &end, 0);
+	  if (end == optarg)
+	    einfo (_("%P%F: unrecognised integer/flag '%s' for PE parameter '%s'\n"),
+		optarg, name);
+	  flags |= value;
+	  optarg = end;
+	}
+      /* If there's any more, we do insist on at least one separator.  */
+      if (optarg && !is_flag_sep (*optarg))
+	einfo (_("%P%F: unparseable at '%s' for PE parameter '%s'\n"),
+	  optarg, name);
+    }
+
+  set_pe_name (name,  flags);
+}
 
 static void
 set_pe_stack_heap (char *resname, char *comname)
@@ -707,6 +816,9 @@ gld${EMULATION_NAME}_handle_option (int 
     case OPTION_DISABLE_LONG_SECTION_NAMES:
       pe_use_coff_long_section_names = 0;
       break;
+    case OPTION_PE_DLL_CHARACTERISTICS:
+      set_pe_value_from_flags ("__dll_characteristics__");
+      break;
     }
   return TRUE;
 }
Index: ld/emultempl/pep.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/pep.em,v
retrieving revision 1.22
diff -p -u -r1.22 pep.em
--- ld/emultempl/pep.em	18 Feb 2009 18:23:07 -0000	1.22
+++ ld/emultempl/pep.em	3 Mar 2009 01:55:06 -0000
@@ -179,7 +179,8 @@ enum options
   OPTION_EXCLUDE_MODULES_FOR_IMPLIB,
   OPTION_USE_NUL_PREFIXED_IMPORT_TABLES,
   OPTION_ENABLE_LONG_SECTION_NAMES,
-  OPTION_DISABLE_LONG_SECTION_NAMES
+  OPTION_DISABLE_LONG_SECTION_NAMES,
+  OPTION_PE_DLL_CHARACTERISTICS
 };
 
 static void
@@ -244,6 +245,7 @@ gld${EMULATION_NAME}_add_options
 #endif
     {"enable-long-section-names", no_argument, NULL, OPTION_ENABLE_LONG_SECTION_NAMES},
     {"disable-long-section-names", no_argument, NULL, OPTION_DISABLE_LONG_SECTION_NAMES},
+    {"pe-dll-characteristics", required_argument, NULL, OPTION_PE_DLL_CHARACTERISTICS},
     {NULL, no_argument, NULL, 0}
   };
 
@@ -256,14 +258,47 @@ gld${EMULATION_NAME}_add_options
 
 typedef struct
 {
+  const char *name;
+  int len;
+  int value;
+} definfoflag;
+
+#define C(name)       { #name, sizeof(#name) - 1, name }
+#define CF(name,flag) { #name, sizeof(#name) - 1, flag }
+static const definfoflag dllchrctnames[] =
+{
+  /* Accept a few handy abbreviations.  */
+  CF(dynbase,     IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
+  CF(forceinteg,  IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
+  CF(nxcompat,    IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
+  CF(noisolation, IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
+  CF(noseh,       IMAGE_DLLCHARACTERISTICS_NO_SEH),
+  CF(nobind,      IMAGE_DLLCHARACTERISTICS_NO_BIND),
+  CF(wdmdriver,   IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
+  CF(tsaware,     IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
+  /* And the full names as defined in the PE specification.  */
+  C(IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
+  C(IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
+  C(IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
+  C(IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
+  C(IMAGE_DLLCHARACTERISTICS_NO_SEH),
+  C(IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
+  C(IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
+  { 0, 0, 0 },
+};
+
+typedef struct
+{
   void *ptr;
   int size;
   bfd_vma value;
   char *symbol;
   int inited;
+  const definfoflag *flagnames;
 } definfo;
 
-#define D(field,symbol,def)  {&pep.field,sizeof(pep.field), def, symbol,0}
+#define D(field,symbol,def)         {&pep.field,sizeof(pep.field), def, symbol, 0, 0}
+#define DF(field,symbol,def,flags)  {&pep.field,sizeof(pep.field), def, symbol, 0, flags}
 
 static definfo init[] =
 {
@@ -271,7 +306,7 @@ static definfo init[] =
 #define IMAGEBASEOFF 0
   D(ImageBase,"__image_base__", NT_EXE_IMAGE_BASE),
 #define DLLOFF 1
-  {&dll, sizeof(dll), 0, "__dll__", 0},
+  {&dll, sizeof(dll), 0, "__dll__", 0, 0},
 #define MSIMAGEBASEOFF	2
   D(ImageBase,"___ImageBase", NT_EXE_IMAGE_BASE),
   D(SectionAlignment,"__section_alignment__", PE_DEF_SECTION_ALIGNMENT),
@@ -288,7 +323,8 @@ static definfo init[] =
   D(SizeOfHeapReserve,"__size_of_heap_reserve__", 0x100000),
   D(SizeOfHeapCommit,"__size_of_heap_commit__", 0x1000),
   D(LoaderFlags,"__loader_flags__", 0x0),
-  { NULL, 0, 0, NULL, 0 }
+  D(DllCharacteristics, "__dll_characteristics__", 0x0),
+  { NULL, 0, 0, NULL, 0, 0 }
 };
 
 
@@ -346,30 +382,51 @@ gld_${EMULATION_NAME}_list_options (FILE
                                        executable image files\n"));
   fprintf (file, _("  --disable-long-section-names       Never use long COFF section names, even\n\
                                        in object files\n"));
+  fprintf (file, _("  --pe-dll-characteristics mes       Never use long COFF section names, even\n\
+                                       an importlib, use <string><basename>.dll\n\
+                                       an importlib, use <string><basename>.dll\n\
+                                       an importlib, use <string><basename>.dll\n\
+                                       an importlib, use <string><basename>.dll\n"));
 #endif
 }
 
+static const definfoflag *
+find_pep_flag_name (char *name, const definfoflag *flagnames)
+{
+  int i;
+
+  /* Look for the name, return pointer to definfoflag if found.  */
+  for (i = 0; flagnames[i].name; i++)
+    if (strncmp (name, flagnames[i].name, flagnames[i].len) == 0)
+      return &flagnames[i];
+  /* Unknown name could be an integer, so not an error here.  */
+  return 0;
+}
 
-static void
-set_pep_name (char *name, bfd_vma val)
+static definfo *
+find_pep_name (char *name)
 {
   int i;
 
-  /* Find the name and set it.  */
+  /* Look for the name, return pointer to definfo.  */
   for (i = 0; init[i].ptr; i++)
-    {
-      if (strcmp (name, init[i].symbol) == 0)
-	{
-	  init[i].value = val;
-	  init[i].inited = 1;
-	  if (strcmp (name,"__image_base__") == 0)
-	    set_pep_name ("___ImageBase", val);
-	  return;
-	}
-    }
+    if (strcmp (name, init[i].symbol) == 0)
+      return &init[i];
+  /* Unknown name is a serious internal coding error, so don't
+     bother to diagnose or return error indication, just bail.  */
   abort ();
 }
 
+static void
+set_pep_name (char *name, long val)
+{
+  /* Find the name and set it.  */
+  definfo *init = find_pep_name (name);
+  init->value = val;
+  init->inited = 1;
+  if (strcmp (name,"__image_base__") == 0)
+    set_pep_name ("___ImageBase", val);
+}
 
 static void
 set_pep_subsystem (void)
@@ -489,6 +546,58 @@ set_pep_value (char *name)
   optarg = end;
 }
 
+static char
+is_flag_sep (char x)
+{
+  return x == '+' || x == '|' || x == ':' || x == ',';
+}
+
+static void
+set_pep_value_from_flags (char *name)
+{
+  long flags = 0;
+  definfo *init;
+
+  /* Look up the symbolic flag names.  Even if there aren't any we
+     will still parse multiple integers combined by separators.  */
+  init = find_pep_name (name);
+
+  /* Parse the flags out of optarg.  We accept any combination of
+     symbolic abbreviations and strtoul-parseable integers, separated
+     by any combination of '+', '|', ':' and ',' characters.  */
+  while (*optarg)
+    {
+      const definfoflag *flag;
+
+      /* Deliberately allow multiple conjoined separators.  */
+      while (is_flag_sep (*optarg))
+	optarg++;
+
+      flag = find_pep_flag_name (optarg, init->flagnames);
+      if (flag)
+	{
+	  flags |= flag->value;
+	  optarg += flag->len;
+	}
+      else
+	{
+	  char *end;
+	  long value;
+	  value = strtoul (optarg, &end, 0);
+	  if (end == optarg)
+	    einfo (_("%P%F: unrecognised integer/flag '%s' for PE parameter '%s'\n"),
+		optarg, name);
+	  flags |= value;
+	  optarg = end;
+	}
+      /* If there's any more, we do insist on at least one separator.  */
+      if (optarg && !is_flag_sep (*optarg))
+	einfo (_("%P%F: unparseable at '%s' for PE parameter '%s'\n"),
+	  optarg, name);
+    }
+
+  set_pep_name (name,  flags);
+}
 
 static void
 set_pep_stack_heap (char *resname, char *comname)
@@ -647,6 +756,9 @@ gld${EMULATION_NAME}_handle_option (int 
     case OPTION_DISABLE_LONG_SECTION_NAMES:
       pep_use_coff_long_section_names = 0;
       break;
+    case OPTION_PE_DLL_CHARACTERISTICS:
+      set_pep_value_from_flags ("__dll_characteristics__");
+      break;
     }
   return TRUE;
 }


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  1:45                 ` Dave Korn
  2009-03-03  2:06                   ` Charles Wilson
@ 2009-03-03  4:28                   ` Christopher Faylor
  2009-03-03  4:51                     ` Dave Korn
  1 sibling, 1 reply; 43+ messages in thread
From: Christopher Faylor @ 2009-03-03  4:28 UTC (permalink / raw)
  To: cygwin

On Mon, Mar 02, 2009 at 10:00:30PM +0000, Dave Korn wrote:
>Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag
>>> by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx
>>>
>>> It would probably be very helpful in the long run if ld had some generic
>>> option to set any of the Windows-specific header flags at build time.
>> 
>> like perhaps a repeatable option
>
>  Yep, this is exactly how I'm doing it.  Patch will be posted shortly.
>Syntax looks like
>
>  --pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]
>
>e.g.
>
>  --pe-dll-characteristics=0x0400|0x0100
>  --pe-dll-characteristics=1+128+1024,noseh,nobind
>  --pe-dll-characteristics noseh:nobind:tsaware

I thought we'd established that these aren't just dll characteristics.

cgf

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  4:28                   ` Christopher Faylor
@ 2009-03-03  4:51                     ` Dave Korn
  2009-03-03  5:07                       ` Christopher Faylor
  0 siblings, 1 reply; 43+ messages in thread
From: Dave Korn @ 2009-03-03  4:51 UTC (permalink / raw)
  To: cygwin

Christopher Faylor wrote:
> On Mon, Mar 02, 2009 at 10:00:30PM +0000, Dave Korn wrote:

>>  --pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]

> I thought we'd established that these aren't just dll characteristics.

  Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff
extension header), so it's canonical, regardless if it also applies to
executables.

    cheers,
      DaveK



--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  4:51                     ` Dave Korn
@ 2009-03-03  5:07                       ` Christopher Faylor
  2009-03-03  5:46                         ` Dave Korn
  0 siblings, 1 reply; 43+ messages in thread
From: Christopher Faylor @ 2009-03-03  5:07 UTC (permalink / raw)
  To: cygwin

On Tue, Mar 03, 2009 at 05:00:28AM +0000, Dave Korn wrote:
>Christopher Faylor wrote:
>>On Mon, Mar 02, 2009 at 10:00:30PM +0000, Dave Korn wrote:
>
>>>--pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]
>
>>I thought we'd established that these aren't just dll characteristics.
>
>Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff
>extension header), so it's canonical, regardless if it also applies to
>executables.

Yes, I am aware of this.

Regardless, I don't think a publicly-exposed interface should be unclear
like this.

cgf

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  5:07                       ` Christopher Faylor
@ 2009-03-03  5:46                         ` Dave Korn
  0 siblings, 0 replies; 43+ messages in thread
From: Dave Korn @ 2009-03-03  5:46 UTC (permalink / raw)
  To: cygwin

Christopher Faylor wrote:
> On Tue, Mar 03, 2009 at 05:00:28AM +0000, Dave Korn wrote:
>> Christopher Faylor wrote:
>>> On Mon, Mar 02, 2009 at 10:00:30PM +0000, Dave Korn wrote:
>>>> --pe-dll-characteristics=<name>|<integer>[(+|,:)<name>|<integer>[...]]
>>> I thought we'd established that these aren't just dll characteristics.
>> Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff
>> extension header), so it's canonical, regardless if it also applies to
>> executables.
> 
> Yes, I am aware of this.
> 
> Regardless, I don't think a publicly-exposed interface should be unclear
> like this.

  We can discuss this in depth on the binutils list when I submit the patch,
there's not much point in having a long OT thread here.  Let's see what the
other PE stakeholders feel.

    cheers,
      DaveK


--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-03  2:44                     ` Dave Korn
@ 2009-03-03 14:31                       ` Dave Korn
  0 siblings, 0 replies; 43+ messages in thread
From: Dave Korn @ 2009-03-03 14:31 UTC (permalink / raw)
  To: Dave Korn; +Cc: cygwin

Dave Korn wrote:
> 
>   Nope, should be easy to cut out the relevant bits, discarding ld-isms, and
> paste the remainder into your code.  Copy of WIP attached for your
> convenience; I've got to add doco and testcases before I can submit it, but
> the parsing stuff is ready to fly and I'd appreciate any extra testing it gets :)

  Two bugfixes FYI:

static void
set_pe_value_from_flags (char *name)

after
      /* Deliberately allow multiple conjoined separators.  */
      while (is_flag_sep (*optarg))
	optarg++;
add
      /* Even trailing at the end.  */
      if (!*optarg)
	break;

change
      /* If there's any more, we do insist on at least one separator.  */
      if (optarg && !is_flag_sep (*optarg))
to
      /* If there's any more, we do insist on at least one separator.  */
      if (*optarg && !is_flag_sep (*optarg))



    cheers,
      DaveK

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-01 10:20             ` Corinna Vinschen
  2009-03-02  3:52               ` Charles Wilson
@ 2009-03-04  6:00               ` Charles Wilson
  2009-03-04  6:01                 ` Charles Wilson
  2009-03-10  0:30               ` [1.7] rebaseall doesn't solve the problem Matthew Woehlke
  2 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-03-04  6:00 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:

> Can you tweak the tool so I can test that next week?

Attached, with Dave's symbolic flagname option parsing included.

It's actually pretty standalone; you ought to be able to just do 'gcc -o
peflags peflags.c' to build it. I'll work on the peflagsall script after
the executable is a little more stable.

The version has been tested moderately, but I wouldn't say thoroughly.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-04  6:00               ` Charles Wilson
@ 2009-03-04  6:01                 ` Charles Wilson
  2009-03-04  8:49                   ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-03-04  6:01 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

Charles Wilson wrote:
> Corinna Vinschen wrote:
> 
>> Can you tweak the tool so I can test that next week?
> 
> Attached,

It helps when you actually attach the file.

--
Chuck

[-- Attachment #2: peflags.c --]
[-- Type: text/plain, Size: 32457 bytes --]

/*
 * Copyright (c) 2009 Charles Wilson
 * Based on rebase.c by Jason Tishler
 * Significant contributions by Dave Korn
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * A copy of the GNU General Public License can be found at
 * http://www.gnu.org/
 */

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <getopt.h>
#include <errno.h>

#include <windows.h>

typedef struct
{
  const char *name;
  int len;
  int value;
} definfoflag;

#define C(name)       { #name, sizeof(#name) - 1, name }
#define CF(name,flag) { #name, sizeof(#name) - 1, flag }
static const definfoflag dllchrctnames[] =
{
  /* Accept a few handy abbreviations.  */
  CF(dynbase,     IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
  CF(forceinteg,  IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
  CF(nxcompat,    IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
  CF(noisolation, IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
  CF(noseh,       IMAGE_DLLCHARACTERISTICS_NO_SEH),
  CF(nobind,      IMAGE_DLLCHARACTERISTICS_NO_BIND),
  CF(wdmdriver,   IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
  CF(tsaware,     IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
  /* And the full names as defined in the PE specification.  */
  C(IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE),
  C(IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY),
  C(IMAGE_DLL_CHARACTERISTICS_NX_COMPAT),
  C(IMAGE_DLLCHARACTERISTICS_NO_ISOLATION),
  C(IMAGE_DLLCHARACTERISTICS_NO_SEH),
  C(IMAGE_DLLCHARACTERISTICS_WDM_DRIVER),
  C(IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE),
  { 0, 0, 0 },
};

static const definfoflag imgfilechrctnames[] =
{
  /* Accept a few handy abbreviations.  */
  CF(wstrim,    IMAGE_FILE_AGGRESIVE_WS_TRIM),
  CF(bigaddr,   IMAGE_FILE_LARGE_ADDRESS_AWARE),
  CF(sepdbg,    IMAGE_FILE_DEBUG_STRIPPED), /* debug info in separate .dbg file */
  /* And the full names as defined in the PE specification.  */
  C(IMAGE_FILE_RELOCS_STRIPPED),
  C(IMAGE_FILE_EXECUTABLE_IMAGE),
  C(IMAGE_FILE_LINE_NUMS_STRIPPED),
  C(IMAGE_FILE_LOCAL_SYMS_STRIPPED),
  C(IMAGE_FILE_AGGRESIVE_WS_TRIM),
  C(IMAGE_FILE_LARGE_ADDRESS_AWARE),
  C(IMAGE_FILE_BYTES_REVERSED_LO),
  C(IMAGE_FILE_32BIT_MACHINE),
  C(IMAGE_FILE_DEBUG_STRIPPED),
  C(IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP),
  C(IMAGE_FILE_NET_RUN_FROM_SWAP),
  C(IMAGE_FILE_SYSTEM),
  C(IMAGE_FILE_DLL),
  C(IMAGE_FILE_UP_SYSTEM_ONLY),
  C(IMAGE_FILE_BYTES_REVERSED_HI),
  { 0, 0, 0 },
};

typedef struct
{
  void *ptr;
  int size;
  int value;
  char *symbol;
  int inited;
  const definfoflag *flagnames;
} definfo;

#define D(var,symbol,def)         {&var,sizeof(var), def, symbol, 0, 0}
#define DF(var,symbol,def,flags)  {&var,sizeof(var), def, symbol, 0, flags}

#define DEFAULT_SHOW_DLL_CHARACTERISTICS 	IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE |\
						IMAGE_DLL_CHARACTERISTICS_NX_COMPAT |\
						IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE
#define DEFAULT_SHOW_IMG_CHARACTERISTICS	0x0
static uint16_t ImgFileCharacteristicsSET;
static uint16_t ImgFileCharacteristicsCLR;
static uint16_t ImgFileCharacteristicsSHOW;
static uint16_t DllCharacteristicsSET;
static uint16_t DllCharacteristicsCLR;
static uint16_t DllCharacteristicsSHOW;

#define SHOWSTR "show__"
static definfo init[] =
{
  DF(ImgFileCharacteristicsSET,  "__img_file_characteristics_set__",     0x0, imgfilechrctnames),
  DF(ImgFileCharacteristicsCLR,  "__img_file_characteristics_clr__",     0x0, imgfilechrctnames),
  DF(ImgFileCharacteristicsSHOW, "__img_file_characteristics_" SHOWSTR,  DEFAULT_SHOW_IMG_CHARACTERISTICS, imgfilechrctnames),
  DF(DllCharacteristicsSET,      "__dll_characteristics_set__",          0x0, dllchrctnames),
  DF(DllCharacteristicsCLR,      "__dll_characteristics_clr__",          0x0, dllchrctnames),
  DF(DllCharacteristicsSHOW,     "__dll_characteristics_" SHOWSTR,       DEFAULT_SHOW_DLL_CHARACTERISTICS, dllchrctnames),
  { NULL, 0, 0, NULL, 0, 0 }
};

#define OPTION_SET_IMAGE_FILE_CHARACTERISTICS    150
#define OPTION_CLR_IMAGE_FILE_CHARACTERISTICS    OPTION_SET_IMAGE_FILE_CHARACTERISTICS+1
#define OPTION_SHOW_IMAGE_FILE_CHARACTERISTICS   OPTION_CLR_IMAGE_FILE_CHARACTERISTICS+1
#define OPTION_SET_DLL_CHARACTERISTICS           OPTION_SHOW_IMAGE_FILE_CHARACTERISTICS+1
#define OPTION_CLR_DLL_CHARACTERISTICS           OPTION_SET_DLL_CHARACTERISTICS+1
#define OPTION_SHOW_DLL_CHARACTERISTICS          OPTION_CLR_DLL_CHARACTERISTICS+1
#define OPTION_FLAG_HELP                         OPTION_SHOW_DLL_CHARACTERISTICS+1
static struct option long_options[] = {
  {"dynbase", required_argument, NULL, 'd'},
  {"tsaware", required_argument, NULL, 't'},
  {"nxcompat", required_argument, NULL, 'n'},
  {"filelist", required_argument, NULL, 'T'},
  {"set-image-characteristics", required_argument, NULL, OPTION_SET_IMAGE_FILE_CHARACTERISTICS},
  {"clr-image-characteristics", required_argument, NULL, OPTION_CLR_IMAGE_FILE_CHARACTERISTICS},
  {"show-image-characteristics", required_argument, NULL, OPTION_SHOW_IMAGE_FILE_CHARACTERISTICS},
  {"set-dll-characteristics", required_argument, NULL, OPTION_SET_DLL_CHARACTERISTICS},
  {"clr-dll-characteristics", required_argument, NULL, OPTION_CLR_DLL_CHARACTERISTICS},
  {"show-dll-characteristics", required_argument, NULL, OPTION_SHOW_DLL_CHARACTERISTICS},
  {"flag-help", no_argument, NULL, OPTION_FLAG_HELP},
  {"verbose", no_argument, NULL, 'v'},
  {"help", no_argument, NULL, 'h'},
  {"version", no_argument, NULL, 'V'},
  {NULL, no_argument, NULL, 0}
};


static const definfoflag *find_pe_flag_name (const char *name, const definfoflag *flagnames);
static definfo *find_pe_name (const char *name);
static void set_pe_name (const char *name, long val);
static void set_pe_by_flagname (const char *name, const char *flagname);
static char is_flag_sep (char x);
static void set_pe_value_from_flags (const char *name);

static void short_usage (FILE *f);
static void help (FILE *f);
static void help_flags (FILE *f);
static void version (FILE *f);

int do_mark (const char *pathname);
int get_characteristics(const char *pathname,
                        uint16_t* pe_img_file_characteristics,
                        uint16_t* pe_dll_characteristics);
int set_pe_img_file_characteristics(const char *pathname,
                                    uint16_t pe_img_file_characteristics);
int set_pe_dll_characteristics(const char *pathname,
                               uint16_t pe_dll_characteristics);
static int pe_get16 (int fd, off_t offset, uint16_t* value);
static int pe_get32 (int fd, off_t offset, uint32_t* value);
static int pe_set16 (int fd, off_t offset, uint16_t value);

static char *symbolic (long flags, const char *name);
static void append_and_decorate (char **str, int is_set, const char *name, int len);
static int strendswith (const char *str, const char *prefix);
static void *xmalloc (size_t num);
#define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
void parse_args (int argc, char *argv[]);
int string_to_bool  (const char *string, int *value);
int string_to_ulong (const char *string, unsigned long *value);
FILE *file_list_fopen (const char *file_list);
char *file_list_fgets (char *buf, int size, FILE *file);
int file_list_fclose (FILE *file);


int args_index = 0;
int verbose = 0;
const char *file_list = 0;
const char *stdin_file_list = "-";

int
main (int argc, char *argv[])
{
  int i = 0;

  parse_args (argc, argv);

  /* Operate on files in file list, if specified. */
  if (file_list)
    {
      int status = 0;
      char filename[MAX_PATH + 2];
      FILE *file = file_list_fopen (file_list);
      if (!file)
	exit (2);

      while (file_list_fgets (filename, MAX_PATH + 2, file))
	{
	  if ((status = do_mark (filename)) != 0)
	    break;
	}

      file_list_fclose (file);
      if (status != 0)
	exit (2);
    }

  /* Operate on files listed as command line arguments. */
  for (i = args_index; i < argc; i++)
    {
      const char *filename = argv[i];
      if (do_mark (filename) != 0)
	exit (2);
    }

  exit (0);
}

int
do_mark (const char *pathname)
{
  int mark_any = FALSE;
  int has_relocs;
  int is_executable;
  int is_dll;
  uint16_t old_img_characteristics;
  uint16_t new_img_characteristics;
  uint16_t old_dll_characteristics;
  uint16_t new_dll_characteristics;
  int i;

  /* Skip if file does not exist */
  if (access (pathname, F_OK) == -1)
    {
      fprintf (stderr, "%s: skipped because nonexistent\n", pathname);
      return 0;
    }

  /* determine if we are actually to write anything. Skip
     entries in init[] that are display oriented */
  for (i = 0; init[i].ptr; i++)
    if (!strendswith (init[i].symbol, SHOWSTR))
      mark_any |= init[i].inited;

  if (mark_any)
    {
      /* Skip if not writable. */
      if (access (pathname, W_OK) == -1)
        {
          fprintf (stderr, "%s: skipped because not writable\n", pathname);
          return 0;
        }
    }

  if (get_characteristics (pathname,
                           &old_img_characteristics,
                           &old_dll_characteristics) != 0)
    {
      fprintf (stderr,
               "%s: skipped because could not read file characteristics\n",
               pathname);
      return 0;
    }
  new_img_characteristics = old_img_characteristics;
  new_img_characteristics |= ImgFileCharacteristicsSET;
  new_img_characteristics &= ~ImgFileCharacteristicsCLR;

  new_dll_characteristics = old_dll_characteristics;
  new_dll_characteristics |= DllCharacteristicsSET;
  new_dll_characteristics &= ~DllCharacteristicsCLR;

  is_executable = ((new_img_characteristics & IMAGE_FILE_EXECUTABLE_IMAGE) > 0);
  is_dll        = ((new_img_characteristics & IMAGE_FILE_DLL) > 0);
  has_relocs    = ((new_img_characteristics & IMAGE_FILE_RELOCS_STRIPPED) == 0);

  /* validation and warnings about things that are
     problematic, but that we are not explicitly
     changing */
  if (!has_relocs)
    {
      if (verbose
         && (new_dll_characteristics & IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE)
         && (old_dll_characteristics & IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE))
        {
          fprintf (stderr,
                   "Warning: file has no relocation info but has dynbase set (%s).\n",
                   pathname);
        }
    }
  if (!is_executable || is_dll)
    {
      if (verbose
         && (new_dll_characteristics & IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE)
         && (old_dll_characteristics & IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE))
        {
          fprintf (stderr,
                   "Warning: file is non-executable but has tsaware set (%s).\n",
                   pathname);
        }
    }
 
  if (mark_any)
    {
      /* validation and warnings about things we are changing */
      if (!has_relocs)
        {
          if (   (new_dll_characteristics & IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE)
             && !(old_dll_characteristics & IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE))
            {
              fprintf (stderr,
                       "Warning: setting dynbase on file with no relocation info (%s).\n",
                       pathname);
            }
        } 

      if (!is_executable || is_dll)
        {
          if (   (new_dll_characteristics & IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE)
             && !(old_dll_characteristics & IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE))
            {
              fprintf (stderr,
                       "Warning: setting tsaware on non-executable (%s).\n",
                       pathname);
            }
        }

      /* setting */
      if (new_img_characteristics != old_img_characteristics)
        if (set_pe_img_file_characteristics (pathname,
                                             new_img_characteristics) != 0)
          {
            fprintf (stderr,
                     "Error: could not update image file characteristics (%s)\n",
                      pathname);
            return 1;
          }
      if (new_dll_characteristics != old_dll_characteristics)
        if (set_pe_dll_characteristics (pathname,
                                        new_dll_characteristics) != 0)
          {
            fprintf (stderr,
                     "Error: could not update dll characteristics (%s)\n",
                      pathname);
            return 1;
          }
    }

  /* Display image characteristics. */
  if (verbose || !mark_any)
    {
      printf ("%s: ", pathname);
      if (ImgFileCharacteristicsSHOW)
        {
          if (old_img_characteristics != new_img_characteristics)
            {
              char * oldImgSymbolic = symbolic(old_img_characteristics,"__img_file_characteristics_" SHOWSTR);
              char * newImgSymbolic = symbolic(new_img_characteristics,"__img_file_characteristics_" SHOWSTR);
              printf ("image-characteristics(0x%04x%s==>0x%04x%s) ",
                  old_img_characteristics,oldImgSymbolic,
                  new_img_characteristics,newImgSymbolic);
              free (oldImgSymbolic);
              free (newImgSymbolic);
            }
          else
            {
              char * oldImgSymbolic = symbolic(old_img_characteristics,"__img_file_characteristics_" SHOWSTR);
              printf ("image-characteristics(0x%04x%s) ",
                  old_img_characteristics,oldImgSymbolic);
              free (oldImgSymbolic);
            }
        }
      else
        {
          if (old_img_characteristics != new_img_characteristics)
            printf ("image-characteristics(0x%04x==>0x%04x) ",
                old_img_characteristics,
                new_img_characteristics);
          else
            printf ("image-characteristics(0x%04x) ",
                old_img_characteristics);
        }
      if (DllCharacteristicsSHOW)
        {
          if (old_dll_characteristics != new_dll_characteristics)
            {
              char * oldDllSymbolic = symbolic(old_dll_characteristics,"__dll_characteristics_" SHOWSTR);
              char * newDllSymbolic = symbolic(new_dll_characteristics,"__dll_characteristics_" SHOWSTR);
              printf ("dll-characteristics(0x%04x%s==>0x%04x%s) ",
                  old_dll_characteristics,oldDllSymbolic,
                  new_dll_characteristics,newDllSymbolic);
              free (oldDllSymbolic);
              free (newDllSymbolic);
            }
          else
            {
              char * oldDllSymbolic = symbolic(old_dll_characteristics,"__dll_characteristics_" SHOWSTR);
              printf ("dll-characteristics(0x%04x%s) ",
                  old_dll_characteristics,oldDllSymbolic);
              free (oldDllSymbolic);
            }
        }
      else
        {
          if (old_dll_characteristics != new_dll_characteristics)
            printf ("dll-characteristics(0x%04x==>0x%04x) ",
                old_dll_characteristics,
                new_dll_characteristics);
          else
            printf ("dll-characteristics(0x%04x) ",
                old_dll_characteristics);
        }
    }

  return 0;
}

static char *
symbolic (long flags, const char *name)
{
  int i;
  long already_marked = 0;
  definfo *someVar = find_pe_name (name);
  char * rVal = NULL;
  for (i = 0; someVar->flagnames[i].name; i++)
    {
      if (someVar->value & someVar->flagnames[i].value & ~already_marked)
        {
          append_and_decorate (&rVal,
            (flags & someVar->flagnames[i].value),
            someVar->flagnames[i].name,
            someVar->flagnames[i].len);
          already_marked |= someVar->flagnames[i].value;
        }
    }
  if (rVal)
    {
      size_t len = strlen (rVal);
      char *tmp = XMALLOC (char, len + 3);
      *tmp = '[';
      memcpy (tmp+1, rVal, len);
      tmp[len+1] = ']';
      tmp[len+2] = '\0';
      free (rVal);
      rVal = tmp;
    }
  return rVal;
}

static void
append_and_decorate (char **str, int is_set, const char *name, int len)
{
  char *tmp;
  int slen;
  if (!*str)
    {
      *str = XMALLOC (char, len + 2);
      (*str)[0] = (is_set ? '+' : '-');
      memcpy ((*str)+1, name, len);
      (*str)[len+1] = '\0';
      return; 
    }
  else
    { 
      slen = strlen (*str);
      tmp = XMALLOC (char, slen + 2 + len + 1);
      memcpy (tmp, *str, slen);
      free (*str);
      *str = tmp;
      tmp = *str + slen;
      *tmp++ = ',';
      *tmp++ = (is_set ? '+' : '-');
      memcpy (tmp, name, len);
      tmp[len] = '\0';
    } 
}

static void *
xmalloc (size_t num)
{
  void *p = (void *) malloc (num);
  if (!p)
    {
      fputs ("Memory exhausted", stderr);
      exit (2);
    }
  return p;
}

static int
strendswith (const char *str, const char *prefix)
{
  size_t slen = strlen (str);
  size_t plen = strlen (prefix);
  if (slen < plen)
    return 0;
  return (strncmp (str + (slen - plen), prefix, plen) == 0);
}

void
parse_args (int argc, char *argv[])
{
  int c;
  int bool_value;
     
  while (1)
    {
      int option_index = 0;
      c = getopt_long (argc, argv, "d:t:n:T:vhV", long_options, &option_index);
      if (c == -1)
        break;

      switch (c)
	{
	case 'h':
	  help (stdout);
          exit (0);
          break;
	case 'V':
	  version (stdout);
	  exit (0);
	  break;
        case OPTION_FLAG_HELP:
          help_flags (stdout);
          exit (0);
          break;

	case 'd':
	  if (string_to_bool (optarg, &bool_value) != 0)
            {
              fprintf (stderr, "Invalid argument for %s: %s\n", 
                       long_options[option_index].name, optarg);
	      short_usage (stderr);
	      exit (1);
            }
          if (bool_value)
            set_pe_by_flagname ("__dll_characteristics_set__", "dynbase");
          else
            set_pe_by_flagname ("__dll_characteristics_clr__", "dynbase");
	  break;
	case 'n':
	  if (string_to_bool (optarg, &bool_value) != 0)
            {
              fprintf (stderr, "Invalid argument for %s: %s\n", 
                       long_options[option_index].name, optarg);
	      short_usage (stderr);
              exit (1);
            }
          if (bool_value)
            set_pe_by_flagname ("__dll_characteristics_set__", "nxcompat");
          else
            set_pe_by_flagname ("__dll_characteristics_clr__", "nxcompat");
	  break;
	case 't':
	  if (string_to_bool (optarg, &bool_value) != 0)
            {
              fprintf (stderr, "Invalid argument for %s: %s\n", 
                       long_options[option_index].name, optarg);
	      short_usage (stderr);
              exit (1);
            }
          if (bool_value)
            set_pe_by_flagname ("__dll_characteristics_set__", "tsaware");
          else
            set_pe_by_flagname ("__dll_characteristics_clr__", "tsaware");
	  break;
	case 'T':
	  file_list = optarg;
	  break;
	case 'v':
	  verbose = TRUE;
	  break;
        case OPTION_SET_IMAGE_FILE_CHARACTERISTICS:
          set_pe_value_from_flags ("__img_file_characteristics_set__");
          break;
        case OPTION_CLR_IMAGE_FILE_CHARACTERISTICS:
          set_pe_value_from_flags ("__img_file_characteristics_clr__");
          break;
        case OPTION_SHOW_IMAGE_FILE_CHARACTERISTICS:
          set_pe_value_from_flags ("__img_file_characteristics_" SHOWSTR);
          break;
        case OPTION_SET_DLL_CHARACTERISTICS:
          set_pe_value_from_flags ("__dll_characteristics_set__");
          break;
        case OPTION_CLR_DLL_CHARACTERISTICS:
          set_pe_value_from_flags ("__dll_characteristics_clr__");
          break;
        case OPTION_SHOW_DLL_CHARACTERISTICS:
          set_pe_value_from_flags ("__dll_characteristics_" SHOWSTR);
          break;
        case '?':
          break;
	default:
	  short_usage (stderr);
	  exit (1);
	  break;
	}
    }

  args_index = optind;

  /* now, iterate thru init[] and apply the accumulated
     values to the global variables */
  for (c = 0; init[c].ptr; c++)
    {
      long val = init[c].value;

      if (init[c].size == sizeof (short))
        *(short *) init[c].ptr = val;
      else if (init[c].size == sizeof (int))
        *(int *) init[c].ptr = val;
      else if (init[c].size == sizeof (long))
        *(long *) init[c].ptr = val;
      else      abort ();
    }
}

int
string_to_bool (const char *string, int *value)
{
  unsigned long number = 0;
  if (!string || !*string)
    return 1;

  if (string_to_ulong (string, &number) != 0)
    {
      size_t len = strlen (string);
      if ( (len == 4 && strcasecmp (string, "true") == 0)
         ||(len == 3 && strcasecmp (string, "yes") == 0) 
         ||(len == 1 && strcasecmp (string, "t") == 0)
         ||(len == 1 && strcasecmp (string, "y") == 0)) 
        {
          *value = TRUE;
        }
      else if ( (len == 5 && strcasecmp (string, "false") == 0)
         ||(len == 2 && strcasecmp (string, "no") == 0) 
         ||(len == 1 && strcasecmp (string, "f") == 0) 
         ||(len == 1 && strcasecmp (string, "n") == 0))
        {
          *value = FALSE;
        }
      else
        {
          return 1;
        }
    }
  else
    {
      *value = (number != 0);
    }
  return 0; 
}

int
string_to_ulong (const char *string, unsigned long *value)
{
  unsigned long number = 0;
  char * endp;
  errno = 0;

  /* null or empty input */
  if (!string || !*string)
    return 1;

  number = strtoul (string, &endp, 0);

  /* out of range */
  if (ERANGE == errno)
    return 1;

  /* no valid numeric input */
  if (endp == string)
    return 1;

  /* non-numeric trailing characters */
  if (*endp != '\0')
    return 1;

  *value = number;
  return 0;
}

int
get_characteristics(const char *pathname,
                    uint16_t* pe_img_file_characteristics,
                    uint16_t* pe_dll_characteristics)
{
  uint32_t pe_header_offset, opthdr_ofs;
  int status = 1;
  int fd, size;
  uint32_t pe_sig;

  fd = open (pathname, O_RDONLY|O_BINARY);
  if (fd == -1)
    goto done;

  if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
    goto done;
  opthdr_ofs = pe_header_offset + 4 + 20;

  pe_sig = 0;
  if (pe_get32 (fd, pe_header_offset, &pe_sig) != 0)
    goto done;
  if (pe_sig != IMAGE_NT_SIGNATURE)
    goto done;

  if (pe_get16 (fd, pe_header_offset + 4 + 18, pe_img_file_characteristics) != 0)
    goto done;

  if (pe_get16 (fd, opthdr_ofs + 70, pe_dll_characteristics) != 0)
    goto done;

  status = 0;

done:
  close (fd);
  return status;
}

int
set_pe_img_file_characteristics(const char *pathname,
                                uint16_t pe_img_file_characteristics)
{
  uint32_t pe_header_offset;
  int status = 1;
  int fd, size;

  /* no extra checking of file's contents below, because
     get_characteristics already did that */
  fd = open (pathname, O_RDWR|O_BINARY);
  if (fd == -1)
    goto done;

  if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
    goto done;

  if (pe_set16 (fd, pe_header_offset + 4 + 18, pe_img_file_characteristics) != 0)
    {
      fprintf (stderr,
               "CATASTROPIC ERROR: attempt to write to file failed! %s could be corrupted; HALTING.\n",
               pathname);
      close (fd);
      exit(2);
    }

  status = 0;

done:
  close (fd);
  return status;
}

int
set_pe_dll_characteristics(const char *pathname,
                           uint16_t pe_dll_characteristics)
{
  uint32_t pe_header_offset, opthdr_ofs;
  int status = 1;
  int fd, size;

  /* no extra checking of file's contents below, because
     get_characteristics already did that */
  fd = open (pathname, O_RDWR|O_BINARY);
  if (fd == -1)
    goto done;

  if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
    goto done;
  opthdr_ofs = pe_header_offset + 4 + 20;

  if (pe_set16 (fd, opthdr_ofs + 70, pe_dll_characteristics) != 0)
    {
      fprintf (stderr,
               "CATASTROPIC ERROR: attempt to write to file failed! %s could be corrupted; HALTING.\n",
               pathname);
      close (fd);
      exit(2);
    }

  status = 0;

done:
  close (fd);
  return status;
}

static int 
pe_get16 (int fd, off_t offset, uint16_t* value)
{
  unsigned char b[2];
  if (lseek (fd, offset, SEEK_SET) == -1)
    return 1;
  if (read (fd, b, 2) != 2)
    return 1;
  *value = b[0] + (b[1]<<8);
  return 0;
}

static int 
pe_get32 (int fd, off_t offset, uint32_t* value)
{
  unsigned char b[4];
  if (lseek (fd, offset, SEEK_SET) == -1)
    return 1;
  if (read (fd, b, 4) != 4)
    return 1;
  *value = b[0] + (b[1]<<8) + (b[2]<<16) + (b[3]<<24);
  return 0;
}

static int 
pe_set16 (int fd, off_t offset, uint16_t value)
{
  unsigned char b[2];
  b[0] = (unsigned char) (value & 0x00ff);
  b[1] = (unsigned char) ((value>>8) & 0x00ff);
  if (lseek (fd, offset, SEEK_SET) == -1)
    return 1;
  if (write (fd, b, 2) != 2)
    return 1;
  return 0;
}

FILE *
file_list_fopen (const char *file_list)
{
  FILE *file = stdin;
  if (strcmp(file_list, stdin_file_list) != 0)
    {
      file = fopen (file_list, "r");
      if (!file)
	fprintf (stderr, "cannot read %s\n", file_list);
    }
  return file;
}

char *
file_list_fgets (char *buf, int size, FILE *file)
{
  char *status = fgets (buf, size, file);
  if (status)
    {
      size_t length = strlen (buf);
      if (buf[length - 1] == '\n')
	buf[length - 1] = '\0';
    }
  return status;
}

int
file_list_fclose (FILE *file)
{
  int status = 0;
  if (strcmp(file_list, stdin_file_list) != 0)
    status = fclose (file);
  return status;
}

static const definfoflag *
find_pe_flag_name (const char *name, const definfoflag *flagnames)
{
  int i;

  /* Look for the name, return pointer to definfoflag if found.  */
  for (i = 0; flagnames[i].name; i++)
    if (strncmp (name, flagnames[i].name, flagnames[i].len) == 0)
      return &flagnames[i];
  /* Unknown name could be an integer, so not an error here.  */
  return 0;
}

static definfo *
find_pe_name (const char *name)
{
  int i;
 
  /* Look for the name, return pointer to definfo.  */
  for (i = 0; init[i].ptr; i++)
    if (strcmp (name, init[i].symbol) == 0)
      return &init[i];
  /* Unknown name is a serious internal coding error, so don't
     bother to diagnose or return error indication, just bail.  */
   abort ();
}

static void
set_pe_by_flagname (const char *name,
                    const char *flagname)
{
  long flags = 0;
  const definfoflag *flag;
  definfo *someVar = find_pe_name (name);

  flag = find_pe_flag_name (flagname, someVar->flagnames);
  if (flag)
    flags |= flag->value;
  else
    fprintf (stderr, "Error: unrecognised integer/flag '%s' for PE parameter '%s'\n",
      optarg, name);

  if (someVar->inited)
    someVar->value |= flags;
  else
    {
      someVar->value = flags;
      someVar->inited = 1;
    }
}

static void
set_pe_name (const char *name, long val)
{
  /* Find the name and set it.  */
  definfo *someVar = find_pe_name (name);
  someVar->value = val;
  someVar->inited = 1;
}
 

static char
is_flag_sep (char x)
{
  return x == '+' || x == '|' || x == ':' || x == ',';
}

static void
set_pe_value_from_flags (const char *name)
{
  long flags = 0;
  definfo *someVar;

  /* Look up the symbolic flag names.  Even if there aren't any we
     will still parse multiple integers combined by separators.  */
  someVar = find_pe_name (name);

  /* Parse the flags out of optarg.  We accept any combination of
     symbolic abbreviations and strtoul-parseable integers, separated
     by any combination of '+', '|', ':' and ',' characters.  */
  while (*optarg)
    {
      const definfoflag *flag;

      /* Deliberately allow multiple conjoined separators.  */
      while (is_flag_sep (*optarg))
        optarg++;

      /* Even trailing at the end.  */
      if (!*optarg)
	break;

      flag = find_pe_flag_name (optarg, someVar->flagnames);
      if (flag)
        {
          flags |= flag->value;
          optarg += flag->len;
        }
      else
        {
          char *end;
          long value;
          value = strtoul (optarg, &end, 0);
          if (end == optarg)
            fprintf (stderr, "Error: unrecognised integer/flag '%s' for PE parameter '%s'\n",
              optarg, name);
          flags |= value;
          optarg = end;
        }
      /* If there's any more, we do insist on at least one separator.  */
      if (*optarg && !is_flag_sep (*optarg))
        fprintf (stderr, "Error: unparseable at '%s' for PE parameter '%s'\n",
          optarg, name);
    }

  set_pe_name (name,  flags);
}

static void
short_usage (FILE *f)
{
  fputs ("Usage: peflags [OPTIONS] file...\n", f);
  fputs ("Sets or clears various flags in PE files (that is, exes and dlls)\n", f);
  fputs ("Use --help for full help text\n", f);
}

static void
help (FILE *f)
{
  fputs ("Usage: peflags [OPTIONS] file...\n", f);
  fputs ("Sets or clears various flags in PE files (that is, exes and dlls)\n", f);
  fputs ("  -d, --dynbase=BOOL                    Sets or clears the dynbase flag\n", f);
  fputs ("  -t, --tsaware=BOOL                    Sets or clears the tsaware flag\n", f);
  fputs ("  -n, --nxcompat=BOOL                   Sets or clears the nxcompat flag\n", f);
  fputs ("  --set-image-characteristics=SPECSTR   Set or clear various flags in the\n", f);
  fputs ("  --clr-image-characteristics=SPECSTR   'Characteristics' field of the PE\n", f);
  fputs ("  --show-image-characteristics=SPECSTR  file's ImageFileHeader.  See winnt.h\n", f);
  fputs ("                                        for possible values. The --show-*h\n", f);
  fputs ("                                        option indicates which flags to\n", f);
  fputs ("                                        display symbolically.n", f);
  fputs ("  --set-dll-characteristics=SPECSTR     Set or clear various flags in the\n", f);
  fputs ("  --clr-dll-characteristics=SPECSTR     'DllCharacteristics' field of the\n", f);
  fputs ("  --show-dll-characteristics=SPECSTR    PE file's ImageOptionalHeader.  See\n", f);
  fputs ("                                        winnt.h for possible values; this\n", f);
  fputs ("                                        field is not only for DLLs\n", f);
  fputs ("  -T, --filelist FILE                   Indicate that FILE contains a list\n", f);
  fputs ("                                        of PE files to process\n", f);
  fputs ("  --verbose                             display diagnostic information\n", f);
  fputs ("  -V, --version                         display version information\n", f);
  fputs ("  -h, --help                            display this help\n", f);
  fputs ("  --flag-help                           display all symbolic flag names\n", f);
  fputs ("\n", f);
  fputs ("BOOL: may be 1, true, or yes - indicates that the flag should be set\n", f);
  fputs ("          if 0, false, or no - indicates that the flag should be cleared\n", f);
  fputs ("\n", f);
  fputs ("SPECSTR: <name>|<integer>[(+|,:)<name>|<integer>[...]]\n", f);
  fputs ("  where <name> is one of several known symbolic names (see --flag-help)\n", f);
  fputs ("  and any of +|;: may be used to join multiple values in a single option\n", f);
}

static void
help_flags (FILE *f)
{
  int i;

  fputs ("Flag help: peflags [OPTIONS] file...\n", f);
  fputs ("The --set-* and --clr-* options accept as an argument a specification\n", f);
  fputs ("string of the following form:\n", f);
  fputs ("   <name>|<integer>[(+|,:)<name>|<integer>[...]]\n", f);
  fputs ("That is, flag values may be expressed using a combination of numeric\n", f);
  fputs ("values and symbolic names.  For example:\n", f);
  fputs ("   --set-dll-characteristics=0x0400|0x0100\n", f);
  fputs ("   --set-dll-characteristics=1+128+1024,noseh,nobind\n", f);
  fputs ("   --set-dll-characteristics=noseh:nobind:tsaware\n", f);
  fputs ("There are a number of these symbolic names, which are listed below\n", f);
  fputs ("  --[set|clr|show]-dll-characteristics:\n", f);

  /* Loop over symbolic names */
  for (i = 0; dllchrctnames[i].name; i++)
    fprintf (f, "      %s\n", dllchrctnames[i].name);
  
  fputs ("  --[set|clr|show]-image-characteristics:\n", f);

  /* Loop over symbolic names */
  for (i = 0; imgfilechrctnames[i].name; i++)
    fprintf (f, "      %s\n", imgfilechrctnames[i].name);
}

static void
version (FILE *f)
{
  fprintf (f, "peflags version %s\n", VERSION);
  fprintf (f, "Copyright (c) 2009  Charles Wilson, Dave Korn, Jason Tishler\n");
}



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-04  6:01                 ` Charles Wilson
@ 2009-03-04  8:49                   ` Corinna Vinschen
  2009-03-04 11:19                     ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-04  8:49 UTC (permalink / raw)
  To: cygwin

On Mar  4 01:01, Charles Wilson wrote:
> Charles Wilson wrote:
> > Corinna Vinschen wrote:
> > 
> >> Can you tweak the tool so I can test that next week?
> > 
> > Attached,
> 
> It helps when you actually attach the file.

Heh :)  Thank you!  I'll give it a whirl on my TS system.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-04  8:49                   ` Corinna Vinschen
@ 2009-03-04 11:19                     ` Corinna Vinschen
  2009-03-04 14:59                       ` Charles Wilson
  0 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-04 11:19 UTC (permalink / raw)
  To: cygwin

On Mar  4 09:49, Corinna Vinschen wrote:
> On Mar  4 01:01, Charles Wilson wrote:
> > Charles Wilson wrote:
> > > Corinna Vinschen wrote:
> > > 
> > >> Can you tweak the tool so I can test that next week?
> > > 
> > > Attached,
> > 
> > It helps when you actually attach the file.
> 
> Heh :)  Thank you!  I'll give it a whirl on my TS system.

Success!

- I removed all Cygwin traces from my TS test machine.
- I disabled DEP for all applications and rebooted (necessary so that the
  next step succeeds).
- I installed a 1.7 distro from scratch.
- I re-enabled DEP for all apps and rebooted.
- I disabled the TS hack in the Cygwin DLL, rebuilt it and installed it
  on the TS machine.
- I started bash and it crashed.
- I started ash (always works for some reason).
- I called "./peflags -t 1 /bin/bash"
- I started bash and... it worked!
- I started GDB and it crashed.
- I called "./peflags -t 1 /bin/gdb"
- I started GDB and it worked.
- I started grep and...
- I called ... /bin/grep
- ... worked.
- ... and ssh ...
- ... and mkpasswd ...
- ... and mkgroup ...

So it seems that setting the TS-aware flag for all applications by
default is the way to go, same as in Visual C++.

Unfortunately that doesn't help us with existing packages in the distro,
only for new ones, but at least we now have the peflags tool for these
cases.

Nevertheless, I will disable the TS hack in Cygwin 1.7 now.  We have a
much better solution now and the hack was a real PITA performance-wise.


Thank you very much for doing that!  I think this deserves a gold star.
Igor?  Are you still with us?  I didn't see a mail from you since October.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-04 11:19                     ` Corinna Vinschen
@ 2009-03-04 14:59                       ` Charles Wilson
  2009-03-04 15:30                         ` Corinna Vinschen
  0 siblings, 1 reply; 43+ messages in thread
From: Charles Wilson @ 2009-03-04 14:59 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:
> Success!
> 
> - I removed all Cygwin traces from my TS test machine.
> - I disabled DEP for all applications and rebooted (necessary so that the
>   next step succeeds).
> - I installed a 1.7 distro from scratch.
> - I re-enabled DEP for all apps and rebooted.
> - I disabled the TS hack in the Cygwin DLL, rebuilt it and installed it
>   on the TS machine.
> - I started bash and it crashed.
> - I started ash (always works for some reason).
> - I called "./peflags -t 1 /bin/bash"

But it seems that the rebase package itself, when built, must be sure to
mark peflags.exe as tsaware before packaging it for distribution,
regardless of which ld.exe is used.  Just in case -- otherwise the poor
TS user won't be able to run peflags to fix everything else?

That leads to a small chicken-and-egg problem if somebody tries to build
the rebase package on a TS system, before the new ld is available.  But
we can live with that.

> - I started bash and... it worked!
> - I started GDB and it crashed.
> - I called "./peflags -t 1 /bin/gdb"
> - I started GDB and it worked.
> - I started grep and...
> - I called ... /bin/grep
> - ... worked.
> - ... and ssh ...
> - ... and mkpasswd ...
> - ... and mkgroup ...

Glad to hear it.

> So it seems that setting the TS-aware flag for all applications by
> default is the way to go, same as in Visual C++.

Makes sense.

> Unfortunately that doesn't help us with existing packages in the distro,
> only for new ones, but at least we now have the peflags tool for these
> cases.

Well, we will soon.  There's still a few things to deal with.
  1) code audit. I'd appreciate a thorough review of the code before
recommending that people use this tool on every app in their
installation.  I know, no warranty express or implied, We're Just Mean,
and You Get To Keep The Pieces, but still...
  2) peflagsall
  3) I'd like to make sure that the interface to peflags and the new
option(s) to ld are the same or very similar.  Once Dave posts his patch
for ld to the binutils list, I'm sure there will be much bike-shedding
about the name of the options, and perhaps discussion about the
implementation. I'd like to wait for ld CVS to be updated with Dave's
eventual contribution after those issues are resolved, and then make
whatever changes to peflags seem appropriate before releasing the tool
"officially".
  4) testing, testing, testing.  Naturally.

Until then, keep the URL to my previous message in this thread handy:
"Download peflags.c from ... and ..." <g>

> Nevertheless, I will disable the TS hack in Cygwin 1.7 now.  We have a
> much better solution now and the hack was a real PITA performance-wise.

I guess, as long as that URL "solution/FAQ answer" is sufficient in the
interim.

> Thank you very much for doing that!  I think this deserves a gold star.
> Igor?  Are you still with us?  I didn't see a mail from you since October.

I'm glad you're pleased with the tsaware facilities, but frankly I'm
happier that the dynbase feature SEEMS to reduce the incidence of fork
problems under Vista!  My previously-working 1.7 installation became
downright unusable last week before I wrote this tool.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-04 14:59                       ` Charles Wilson
@ 2009-03-04 15:30                         ` Corinna Vinschen
  2009-03-05  3:39                           ` peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem] Charles Wilson
  0 siblings, 1 reply; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-04 15:30 UTC (permalink / raw)
  To: cygwin

On Mar  4 09:59, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > [...]
> > - I called "./peflags -t 1 /bin/bash"
> 
> But it seems that the rebase package itself, when built, must be sure to
> mark peflags.exe as tsaware before packaging it for distribution,
> regardless of which ld.exe is used.  Just in case -- otherwise the poor
> TS user won't be able to run peflags to fix everything else?

Well, my peflags.exe was not TS-aware and worked on TS.  The bad joke
is that some applications get broken by tsappcmp.dll and some not.
I don't see any pattern.  The below list (bash, ssh, grep, gdb, mkpasswd,
mkgroup) is what I found to get screwed up, other stuff like ash, gawk,
ls, nm, peflags, work fine.

> > So it seems that setting the TS-aware flag for all applications by
> > default is the way to go, same as in Visual C++.
> 
> Makes sense.
> 
> > Unfortunately that doesn't help us with existing packages in the distro,
> > only for new ones, but at least we now have the peflags tool for these
> > cases.
> 
> Well, we will soon.  There's still a few things to deal with.
>   1) code audit. I'd appreciate a thorough review of the code before
> recommending that people use this tool on every app in their
> installation.  I know, no warranty express or implied, We're Just Mean,
> and You Get To Keep The Pieces, but still...

Well, I had a few tiny problems:

- VERSION wasn't defined for some reason.
- Just for kicks, try `peflags --show-image-characteristics=tsaware /bin/bash'
  (note: tsaware is a dll-characteristic, not an image-characteristic...)
- Stuff like `./peflags.exe --show-dll-characteristics=tsaware' prints
  nothing at all.  I guess it should print a help message due to a missing
  parameter instead.
- peflags --help is missing linebreaks (line 1004 is missing a backslash

>   2) peflagsall
>   3) I'd like to make sure that the interface to peflags and the new
> option(s) to ld are the same or very similar.  Once Dave posts his patch
> for ld to the binutils list, I'm sure there will be much bike-shedding
> about the name of the options, and perhaps discussion about the
> implementation. I'd like to wait for ld CVS to be updated with Dave's
> eventual contribution after those issues are resolved, and then make
> whatever changes to peflags seem appropriate before releasing the tool
> "officially".

Makes sense.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem]
  2009-03-04 15:30                         ` Corinna Vinschen
@ 2009-03-05  3:39                           ` Charles Wilson
  2009-03-05  3:55                             ` Dave Korn
  2009-03-16  6:33                             ` peflags utility Charles Wilson
  0 siblings, 2 replies; 43+ messages in thread
From: Charles Wilson @ 2009-03-05  3:39 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Corinna Vinschen wrote:
> Well, I had a few tiny problems:
> 
> - VERSION wasn't defined for some reason.

Yeah, oops. That was -Ddefined by the makefile rule.

> - Just for kicks, try `peflags --show-image-characteristics=tsaware /bin/bash'
>   (note: tsaware is a dll-characteristic, not an image-characteristic...)

My fault when de-binutils-ifying Dave's patch.  einfo() never returns,
but I replaced it with fprintf(stderr,...).  Fixed.

> - Stuff like `./peflags.exe --show-dll-characteristics=tsaware' prints
>   nothing at all.  I guess it should print a help message due to a missing
>   parameter instead.

Fixed.

> - peflags --help is missing linebreaks (line 1004 is missing a backslash

Typo.  '.' is right next to '\'.

Patch attached (and gzipped copy of fully-patched .c file).   Still need
to compile using -DVERSION='"2.4.5"' or something:

gcc -o peflags.exe -DVERSION='"2.4.5"' peflags.c

Dave: none of Corinna's comments, nor my changes in addressing them,
point to any issues with your original patch for binutils.

--
Chuck



[-- Attachment #2: peflags.c.20090304.patch --]
[-- Type: application/x-patch, Size: 8179 bytes --]

[-- Attachment #3: peflags.c.20090304.gz --]
[-- Type: application/gzip, Size: 7441 bytes --]

[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem]
  2009-03-05  3:39                           ` peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem] Charles Wilson
@ 2009-03-05  3:55                             ` Dave Korn
  2009-03-16  6:33                             ` peflags utility Charles Wilson
  1 sibling, 0 replies; 43+ messages in thread
From: Dave Korn @ 2009-03-05  3:55 UTC (permalink / raw)
  To: cygwin

Charles Wilson wrote:

> Dave: none of Corinna's comments, nor my changes in addressing them,
> point to any issues with your original patch for binutils.

  Yep, so I see; I'm lurking.

    cheers,
      DaveK

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-01 10:20             ` Corinna Vinschen
  2009-03-02  3:52               ` Charles Wilson
  2009-03-04  6:00               ` Charles Wilson
@ 2009-03-10  0:30               ` Matthew Woehlke
  2009-03-10 13:34                 ` Charles Wilson
  2 siblings, 1 reply; 43+ messages in thread
From: Matthew Woehlke @ 2009-03-10  0:30 UTC (permalink / raw)
  To: cygwin

Corinna Vinschen wrote:
> On Feb 28 16:18, Charles Wilson wrote:
>> I'm open to suggestions.  "peimgflags"?  Currently, aslr only
> 
> peflags?

$0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That 
way it's a verb instead of a noun...

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"You know what Microsoft's problem really is? They've lost the ability 
to feel ashamed." -- Pamela Jones (Groklaw)


--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-10  0:30               ` [1.7] rebaseall doesn't solve the problem Matthew Woehlke
@ 2009-03-10 13:34                 ` Charles Wilson
  2009-03-10 18:39                   ` Matthew Woehlke
  2009-03-11  3:55                   ` ABCD
  0 siblings, 2 replies; 43+ messages in thread
From: Charles Wilson @ 2009-03-10 13:34 UTC (permalink / raw)
  To: cygwin

Matthew Woehlke wrote:
> Corinna Vinschen wrote:
>> On Feb 28 16:18, Charles Wilson wrote:
>>> I'm open to suggestions.  "peimgflags"?  Currently, aslr only
>>
>> peflags?
> 
> $0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
> way it's a verb instead of a noun...
> 

...except that the utility can also be used to display the flag values,
as well. So 'ch*' (as in 'change*') isn't very accurate, either.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-10 13:34                 ` Charles Wilson
@ 2009-03-10 18:39                   ` Matthew Woehlke
  2009-03-11  3:55                   ` ABCD
  1 sibling, 0 replies; 43+ messages in thread
From: Matthew Woehlke @ 2009-03-10 18:39 UTC (permalink / raw)
  To: cygwin

Charles Wilson wrote:
> Matthew Woehlke wrote:
>> Corinna Vinschen wrote:
>>> On Feb 28 16:18, Charles Wilson wrote:
>>>> I'm open to suggestions.  "peimgflags"?  Currently, aslr only
>>> peflags?
>> $0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
>> way it's a verb instead of a noun...
>>
> 
> ....except that the utility can also be used to display the flag values,
> as well. So 'ch*' (as in 'change*') isn't very accurate, either.

Yes, I found that after I'd sent the above :-). Ah, well.

If the command is 'peflags --set-<blah>' (as is the case currently 
IIUC), I think that's fine.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Still the prettiest." -- Legolas
(as quoted in The Very Secret Diaries by Cassandra Claire)
http://www.ealasaid.com/misc/vsd/


--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
  2009-03-10 13:34                 ` Charles Wilson
  2009-03-10 18:39                   ` Matthew Woehlke
@ 2009-03-11  3:55                   ` ABCD
  1 sibling, 0 replies; 43+ messages in thread
From: ABCD @ 2009-03-11  3:55 UTC (permalink / raw)
  To: cygwin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles Wilson wrote:
> Matthew Woehlke wrote:
>> Corinna Vinschen wrote:
>>> On Feb 28 16:18, Charles Wilson wrote:
>>>> I'm open to suggestions.  "peimgflags"?  Currently, aslr only
>>> peflags?
>> $0.02 from a mostly-lurker-these-days: chpe{h,hdr,header,f,flags}? That
>> way it's a verb instead of a noun...
>>
> 
> ...except that the utility can also be used to display the flag values,
> as well. So 'ch*' (as in 'change*') isn't very accurate, either.
> 
> --
> Chuck
> 
> 

USD0.02 from another lurker: split it into two programs, lspeflags and
chpeflags (or whatever)?

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm2mFkACgkQOypDUo0oQOr5BgCdF/ylr0/+sM3jF7d9XpLnz4I3
wrMAoIkZBple24MfvzpVNA3MCwOgjO8D
=3pGf
-----END PGP SIGNATURE-----


--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: peflags utility
  2009-03-05  3:39                           ` peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem] Charles Wilson
  2009-03-05  3:55                             ` Dave Korn
@ 2009-03-16  6:33                             ` Charles Wilson
  2009-03-16 12:43                               ` Corinna Vinschen
  2009-03-17  6:49                               ` Charles Wilson
  1 sibling, 2 replies; 43+ messages in thread
From: Charles Wilson @ 2009-03-16  6:33 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Here's revision 3. I've revised the UI to be more like what was
eventually accepted by binutils.  One difference is that the ld options
allow only to set flags:
  ld --tsaware

With peflags we can set, clear, or display them:
  peflags --tsaware    : display
  peflags --tsaware=1  : set
  peflags --tsaware=0  : clear

If this is more-or-less ok, I'll get started on the peflagsall script,
and send it all with updated docu as a patch for Jason to use in the
next rebase release.

gcc -o peflags.exe -DVERSION='"2.4.5"' peflags.c

--
Chuck


[-- Attachment #2: peflags.c.20090315.gz --]
[-- Type: application/gzip, Size: 6050 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: peflags utility
  2009-03-16  6:33                             ` peflags utility Charles Wilson
@ 2009-03-16 12:43                               ` Corinna Vinschen
  2009-03-17  6:49                               ` Charles Wilson
  1 sibling, 0 replies; 43+ messages in thread
From: Corinna Vinschen @ 2009-03-16 12:43 UTC (permalink / raw)
  To: cygwin

On Mar 16 02:32, Charles Wilson wrote:
> Here's revision 3. I've revised the UI to be more like what was
> eventually accepted by binutils.  One difference is that the ld options
> allow only to set flags:
>   ld --tsaware
> 
> With peflags we can set, clear, or display them:
>   peflags --tsaware    : display
>   peflags --tsaware=1  : set
>   peflags --tsaware=0  : clear
> 
> If this is more-or-less ok, I'll get started on the peflagsall script,
> and send it all with updated docu as a patch for Jason to use in the
> next rebase release.
> 
> gcc -o peflags.exe -DVERSION='"2.4.5"' peflags.c

Looks good, except for three minor details I found.  Patch attached.

- The output is missing a trailing \n.

- Error output is missing an error description:

    $ ./peflags --tsaware=1 /bin/tcsh
    Error: could not update pe characteristics (/bin/tcsh)

  Yes, but... why?  The patch adds errno output, like this:

    $ ./peflags --tsaware=1 /bin/tcsh
    Error: could not update pe characteristics (/bin/tcsh): Device or resource busy

- The get/set characteristics function are calling close(fd) even
  if open failed.  This leads to wrong errno output after applying the
  above errno output.


Corinna


--- peflags.c.ORIG	2009-03-16 13:18:06.000000000 +0100
+++ peflags.c	2009-03-16 13:37:55.000000000 +0100
@@ -317,16 +317,16 @@ do_mark (const char *pathname)
         if (set_coff_characteristics (pathname,new_coff_characteristics) != 0)
           {
             fprintf (stderr,
-                     "Error: could not update coff characteristics (%s)\n",
-                      pathname);
+                     "Error: could not update coff characteristics (%s): %s\n",
+                      pathname, strerror (errno));
             return 1;
           }
       if (new_pe_characteristics != old_pe_characteristics)
         if (set_pe_characteristics (pathname,new_pe_characteristics) != 0)
           {
             fprintf (stderr,
-                     "Error: could not update pe characteristics (%s)\n",
-                      pathname);
+                     "Error: could not update pe characteristics (%s): %s\n",
+                      pathname, strerror (errno));
             return 1;
           }
     }
@@ -393,6 +393,7 @@ do_mark (const char *pathname)
           else
             printf ("pe(0x%04x) ", old_pe_characteristics);
         }
+      puts ("");
     }
 
   return 0;
@@ -704,7 +705,7 @@ get_characteristics(const char *pathname
 
   fd = open (pathname, O_RDONLY|O_BINARY);
   if (fd == -1)
-    goto done;
+    return status;
 
   if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
     goto done;
@@ -741,7 +742,7 @@ set_coff_characteristics(const char *pat
      get_characteristics already did that */
   fd = open (pathname, O_RDWR|O_BINARY);
   if (fd == -1)
-    goto done;
+    return status;
 
   if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
     goto done;
@@ -774,7 +775,7 @@ set_pe_characteristics(const char *pathn
      get_characteristics already did that */
   fd = open (pathname, O_RDWR|O_BINARY);
   if (fd == -1)
-    goto done;
+    return status;
 
   if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
     goto done;


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: peflags utility
  2009-03-16  6:33                             ` peflags utility Charles Wilson
  2009-03-16 12:43                               ` Corinna Vinschen
@ 2009-03-17  6:49                               ` Charles Wilson
  1 sibling, 0 replies; 43+ messages in thread
From: Charles Wilson @ 2009-03-17  6:49 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Charles Wilson wrote:

> If this is more-or-less ok, I'll get started on the peflagsall script,
> and send it all with updated docu as a patch for Jason to use in the
> next rebase release.

Incorporating Corinna's patch, with a peflagsall script and updated
documentation and Makefile patches. I even used it on my entire
installation with no ill effects.

Jason?  (I arbitrarily bumped the version number to 2.9.8, but whatever
you choose is fine).

--
Chuck

[-- Attachment #2: rebase-2.4.4-1.20090316.patch.gz --]
[-- Type: application/gzip, Size: 12944 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
@ 2009-04-09  3:55 Charles Wilson
  0 siblings, 0 replies; 43+ messages in thread
From: Charles Wilson @ 2009-04-09  3:55 UTC (permalink / raw)
  To: cygwin

Jonathan wrote:
> I've read the entire thread here
> http://cygwin.com/ml/cygwin/2009-02/msg00488.html and it seems to be the
> exact same problem I'm having.  Discussion seems to have stopped though,
> I didn't seem any emails on it for the last three weeks or so.  Is this
> fix or tool ready for end users, or testers?  I've seen this rebase
> issue on Vista with both Perl and Python.

rebase-3.0-2 was announced here:
http://cygwin.com/ml/cygwin/2009-04/msg00174.html
and it includes the new peflags tool and peflagsall script.

However...

I've found that setting the ASLR flag on the DLLs *helps* on Vista --
but doesn't always work.  Sometimes I'll still get the "fatal error -
unable to remap" issue. This usually happens when:

1) The computer has recently hibernated
2) And I'm doing a TON of perl stuff with lots of fork/execs (e.g.
autoreconf).

It usually fixes itself if you reboot.  This allows Vista to re-allocate
the random base addresses, AND actually obey them.  It's as if it
"forgets" about ASLR after hibernation.

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [1.7] rebaseall doesn't solve the problem
@ 2009-04-09  3:18 Jonathan
  0 siblings, 0 replies; 43+ messages in thread
From: Jonathan @ 2009-04-09  3:18 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

I've read the entire thread here
http://cygwin.com/ml/cygwin/2009-02/msg00488.html and it seems to be the
exact same problem I'm having.  Discussion seems to have stopped though,
I didn't seem any emails on it for the last three weeks or so.  Is this
fix or tool ready for end users, or testers?  I've seen this rebase
issue on Vista with both Perl and Python.

Thanks,
Jonathan

[Below was written before reading the thread linked above]

cygcheck output is attached minus the registry information, cygcheck
seems to go into an endless loop on 64bit Vista when dumping registry
information.

I'm trying to run the django test server on a new created project with a
trunk checkout of django.  I have updated cygwin to the latest version
and reinstalled python as well.

% python manage.py runserver
     90 [main] python 3852 C:\cygwin\bin\python.exe: *** fatal error -
unable to remap C:\cygwin\bin\cygssl-0.9.8.dll to same address as
parent(0x6B4A0000) != 0x6B4B0000
      2 [main] python 5732 fork: child 3852 - died waiting for dll
loading, errno 11

% python manage.py runserver
      2 [main] python 6664 C:\cygwin\bin\python.exe: *** fatal error -
unable to remap C:\cygwin\bin\cygssl-0.9.8.dll to same address as
parent(0x6B4A0000) != 0x6B4B0000
      3 [main] python 6748 fork: child 6664 - died waiting for dll
loading, errno 11

Any help is much appreciated,
Jonathan

[-- Attachment #2: cygcheck.out --]
[-- Type: text/plain, Size: 4590 bytes --]


Cygwin Configuration Diagnostics
Current System Time: Wed Apr 08 21:03:18 2009

Windows Vista Ultimate Ver 6.0 Build 6001 Service Pack 1

Running under WOW64 on AMD64

Path:	C:\j2sdk1.4.2_06\bin
	.\
	C:\cygwin\usr\local\bin
	C:\cygwin\bin
	C:\cygwin\bin
	.\
	C:\cygwin\bin
	C:\cygwin\usr\X11R6\bin
	C:\cygwin\usr\X11R6\bin
	C:\cygwin\usr\X11R6\bin
	C:\cygwin\home\Jonathan\bin

Output from c:\cygwin\bin\id.exe (nontsec)
UID: 1000(Jonathan) GID: 513(None)
0(root)             544(Administrators) 545(Users)          513(None)
10545(Users)

Output from c:\cygwin\bin\id.exe (ntsec)
UID: 1000(Jonathan) GID: 513(None)
0(root)             544(Administrators) 545(Users)          513(None)
10545(Users)

SysDir: C:\Windows\system32
WinDir: C:\Windows

HOME = '/home/Jonathan'
PWD = '/cygdrive/c/Users/Jonathan/Desktop'
USER = 'jonathan'
MAKE_MODE = 'unix'

!:: = '::\'
!C: = 'C:\'
!ExitCode = '00000000'
ALLUSERSPROFILE = 'C:\ProgramData'
APPDATA = 'C:\Users\Jonathan\AppData\Roaming'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
CommonProgramW6432 = 'C:\Program Files\Common Files'
COMPUTERNAME = 'SAGER9262'
COMSPEC = 'C:\Windows\system32\cmd.exe'
configsetroot = 'C:\Windows\ConfigSetRoot'
CYGWIN_ROOT = '\cygwin'
DFSTRACINGON = 'FALSE'
DISPLAY = '127.0.0.1:0.0'
FP_NO_HOST_CHECK = 'NO'
HOMEDRIVE = 'C:'
HOMEPATH = '\Users\Jonathan'
LOCALAPPDATA = 'C:\Users\Jonathan\AppData\Local'
LOGONSERVER = '\\SAGER9262'
NUMBER_OF_PROCESSORS = '4'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_ARCHITEW6432 = 'AMD64'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 23 Stepping 7, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '1707'
ProgramData = 'C:\ProgramData'
PROGRAMFILES = 'C:\Program Files (x86)'
ProgramFiles(x86) = 'C:\Program Files (x86)'
ProgramW6432 = 'C:\Program Files'
PROMPT = '$P$G'
PUBLIC = 'C:\Users\Public'
RUN = '\cygwin\bin\run -p /usr/X11R6/bin'
SESSIONNAME = 'Console'
SYSTEMDRIVE = 'C:'
SYSTEMROOT = 'C:\Windows'
TERM = 'xterm'
TRACE_FORMAT_SEARCH_PATH = '\\NTREL202.ntdev.corp.microsoft.com\34FB5F65-FFEB-4B61-BF0E-A6A76C450FAA\TraceFormat'
USERDOMAIN = 'SAGER9262'
USERNAME = 'jonathan'
USERPROFILE = 'C:\Users\Jonathan'
WINDIR = 'C:\Windows'
XAPPLRESDIR = '/usr/X11R6/lib/X11/app-defaults'
XCMSDB = '/usr/X11R6/lib/X11/Xcms.txt'
XKEYSYMDB = '/usr/X11R6/lib/X11/XKeysymDB'
XNLSPATH = '/usr/X11R6/lib/X11/locale'
WINDOWID = '2097190'
XTERM_VERSION = 'Cygwin 6.8.99.903(242)'
XTERM_LOCALE = 'C'
LOGNAME = 'jonathan'
TERMCAP = 'xterm-r6|xterm|xterm X11R6 version:am:km:mi:ms:xn:co#145:it#8:li#53:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:'
XTERM_SHELL = '/usr/bin/tcsh'
HOSTTYPE = 'i386-cygwin'
VENDOR = 'intel'
OSTYPE = 'cygwin'
MACHTYPE = 'i386'
SHLVL = '1'
GROUP = 'None'
HOST = 'SAGER9262'
REMOTEHOST = '127.0.0.1'
MANPATH = ':/usr/ssl/man'
PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig'
SHELL = '/bin/tcsh'
PAGER = 'less'
BLOCKSIZE = 'K'

Use '-r' to scan registry

obcaseinsensitive set to 1

c:  hd  NTFS     51200Mb  89% CP CS UN PA FC     
d:  cd             N/A    N/A                    
e:  hd  NTFS    238472Mb  91% CP CS UN PA FC     SimpleDrive
f:  cd             N/A    N/A                    
q:  hd  NTFS    202840Mb  87% CP CS UN PA FC     
r:  hd  NTFS    305242Mb  85% CP CS UN PA FC     

c:\cygwin      /          system  binmode
C:\cygwin\bin  /usr/bin   system  binmode
C:\cygwin\lib  /usr/lib   system  binmode
.              /cygdrive  user    binmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\awk.exe
 -> C:\cygwin\bin\gawk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\cpp.exe


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2009-04-09  3:18 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-21  2:27 [1.7] rebaseall doesn't solve the problem Charles Wilson
2009-02-24 10:06 ` Corinna Vinschen
2009-02-27 21:22   ` Charles Wilson
2009-02-28 10:43     ` Corinna Vinschen
2009-02-28 18:50       ` Charles Wilson
2009-02-28 19:34         ` Matt Wozniski
2009-02-28 19:51         ` Christopher Faylor
2009-02-28 20:04           ` Charles Wilson
2009-02-28 20:29           ` Corinna Vinschen
2009-02-28 21:30             ` Charles Wilson
2009-03-01  9:47               ` Corinna Vinschen
2009-03-01 10:05                 ` Corinna Vinschen
2009-03-02 12:08             ` Corinna Vinschen
2009-03-02 15:14               ` Charles Wilson
2009-03-03  1:45                 ` Dave Korn
2009-03-03  2:06                   ` Charles Wilson
2009-03-03  2:44                     ` Dave Korn
2009-03-03 14:31                       ` Dave Korn
2009-03-03  4:28                   ` Christopher Faylor
2009-03-03  4:51                     ` Dave Korn
2009-03-03  5:07                       ` Christopher Faylor
2009-03-03  5:46                         ` Dave Korn
2009-02-28 20:16         ` Corinna Vinschen
2009-02-28 21:19           ` Charles Wilson
2009-03-01 10:20             ` Corinna Vinschen
2009-03-02  3:52               ` Charles Wilson
2009-03-04  6:00               ` Charles Wilson
2009-03-04  6:01                 ` Charles Wilson
2009-03-04  8:49                   ` Corinna Vinschen
2009-03-04 11:19                     ` Corinna Vinschen
2009-03-04 14:59                       ` Charles Wilson
2009-03-04 15:30                         ` Corinna Vinschen
2009-03-05  3:39                           ` peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem] Charles Wilson
2009-03-05  3:55                             ` Dave Korn
2009-03-16  6:33                             ` peflags utility Charles Wilson
2009-03-16 12:43                               ` Corinna Vinschen
2009-03-17  6:49                               ` Charles Wilson
2009-03-10  0:30               ` [1.7] rebaseall doesn't solve the problem Matthew Woehlke
2009-03-10 13:34                 ` Charles Wilson
2009-03-10 18:39                   ` Matthew Woehlke
2009-03-11  3:55                   ` ABCD
2009-04-09  3:18 Jonathan
2009-04-09  3:55 Charles Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).