On Tue, Apr 18, 2023 at 9:44 AM Corinna Vinschen
wrote:
> Pash pushed. I new rebase 4.6.3 release with your patch is just
> building.
Thanks!
This allows for setting, clearing, and displaying the value of the
"control flow guard" dll characteristics flag.
The flag for MSVC is called "/guard:cf" and the macro ends with "GUARD_CF".
To keep things consistent, it would make sense to name the option "guard-cf".
However, there's already
Jeremy noted that an option already exists in genpeimage [0] but with
a different name, which I wasn't aware of: -c/control-flow-guard,
instead of -g/guard-cf which I used here. I'm open to making them
match.
[0]
This allows for setting, clearing, and displaying the value of the
"control flow guard" dll characteristics flag.
For the option naming something like cfguard would probably be
easier to understand, but the MSVC flag is "/guard:cf" and the macro
contains GUARD_CF, so use "guard-cf" for
After the upgrade to 3.4 (disclaimer: in MSYS2) I'm seeing, and getting reports
of, various things failing in Docker only, for example:
1 [main] pacman 252 child_copy: dll data read copy failed,
0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 5096, Win32 error
299
0 [main] pacman
I can confirm that reverting the asm change in
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=188d5f6c9ad5cbbd6f0fcb9aaf15bc9870597910
seems to make things work again.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
The following example works with 3.3.6, but fails with 3.4.2. It's a
reduced example from pacman which started to produce garbage output in
some places after upgrading to 3.4.2. While I noticed it in MSYS2
first, I have confirmed it with 3.3.6 and 3.4.2 in cygwin.
```
#include
#include
#include
On Fri, Mar 19, 2021 at 11:09 AM Takashi Yano via Cygwin
wrote:
>
> On Thu, 18 Mar 2021 21:28:40 +0100
> Christoph Reiter wrote:
> > I noticed that the stdin pipe was renamed from
> >
> > "\msys-dd50a72ab4668b33-pty1-from-master" to
> > "\msys-dd50a72ab4668b33-pty0-to-slave" in
> >
On Fri, Mar 19, 2021 at 4:47 AM Brian Inglis
wrote:
>
> On 2021-03-18 14:28, Christoph Reiter via Cygwin wrote:
> If these are being renamed should they not now use neutral terminology based
> on
> terms such as primary and secondary, and the primary/default repo branches
Hey,
I noticed that the stdin pipe was renamed from
"\msys-dd50a72ab4668b33-pty1-from-master" to
"\msys-dd50a72ab4668b33-pty0-to-slave" in
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=bb42852062073439
This trips up https://github.com/k-takata/ptycheck to detect the
cygpty which is
On Fri, Mar 5, 2021 at 5:50 PM L A Walsh wrote:
> Really I don't see a compelling reason there should be
> any hurry to update. In my own testing, I've been unable to
> build a version that doesn't crash/dump core on linux and don't
> really think the 5.x series has had a thorough
On Sun, Feb 28, 2021 at 3:22 PM ASSI wrote:
>
> Christoph Reiter via Cygwin writes:
> > MSYS2 builds all packages with ASLR since 6 months, so things look
> > good.
>
> That doesn't tell you all that much since you will have to wait for some
> unfavorable address
On Sun, Feb 28, 2021 at 1:16 PM ASSI wrote:
>
> Christoph Reiter via Cygwin writes:
> > binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled
> > linker
> > will give you:
> >
> >> peflags -v mydll.dll
> > mydll.dll: coff(0x2026[+
Hey,
binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled linker
will give you:
> peflags -v mydll.dll
mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll])
pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat])
Is this still problematic for cygwin?
The
14 matches
Mail list logo
