Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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'

Re: [1.7] rebaseall doesn't solve the problem

-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,he

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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... > ...exce

Re: [1.7] rebaseall doesn't solve the problem

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 addre

Re: peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem]

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:

peflags utility [Was: Re: [1.7] rebaseall doesn't solve the problem]

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-

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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 disabl

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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 /* * Copyright (c) 2009 Charles Wilson * Based on rebase.c by Jason Tishler * Significant contributions by Dave Korn *

Re: [1.7] rebaseall doesn't solve the problem

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 ex

Re: [1.7] rebaseall doesn't solve the problem

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 appreciat

Re: [1.7] rebaseall doesn't solve the problem

Christopher Faylor wrote: > On Tue, Mar 03, 2009 at 05:00:28AM +, Dave Korn wrote: >> Christopher Faylor wrote: >>> On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=|[(+|,:)|[...]] >>> I thought we'd established that these aren't just dll characteristics.

Re: [1.7] rebaseall doesn't solve the problem

On Tue, Mar 03, 2009 at 05:00:28AM +, Dave Korn wrote: >Christopher Faylor wrote: >>On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: > >>>--pe-dll-characteristics=|[(+|,:)|[...]] > >>I thought we'd established that these aren't just dll characteristics. > >Well, it's the name of the f

Re: [1.7] rebaseall doesn't solve the problem

Christopher Faylor wrote: > On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: >> --pe-dll-characteristics=|[(+|,:)|[...]] > 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),

Re: [1.7] rebaseall doesn't solve the problem

On Mon, Mar 02, 2009 at 10:00:30PM +, 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

Re: [1.7] rebaseall doesn't solve the problem

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=|[(+|,:)|[...]] >> >> e.g. >> >> --pe-dll-characteristics=0x0400|0x0100 >> --pe-dll-characteristics=1+128+1024,noseh,nobind >

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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 t

Re: [1.7] rebaseall doesn't solve the problem

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 f

Re: [1.7] rebaseall doesn't solve the problem

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, D

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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 su

Re: [1.7] rebaseall doesn't solve the problem

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 w

Re: [1.7] rebaseall doesn't solve the problem

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 Cygwi

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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

Re: [1.7] rebaseall doesn't solve the problem

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 s

Re: [1.7] rebaseall doesn't solve the problem

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. We

Re: [1.7] rebaseall doesn't solve the problem

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, > > on

Re: [1.7] rebaseall doesn't solve the problem

Corinna Vinschen wrote: >> which means that locale.nls extends all the way down to 0x005E1000, so >> Cwd.dll can't go at 0x0086. > > 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 i

Re: [1.7] rebaseall doesn't solve the problem

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: 0x5d6a > L

[1.7] rebaseall doesn't solve the problem

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(0x86) != 0x14E 5 [main] perl 3636 child