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


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

resend: Re: [PATCH] strace: Fix crash caused over-optimization


sourceware.org decided that I was a spammer for some weird reason... Maybe this one will go through...

On 04/19/2017 10:52 AM, MAILER-DAEMON@sourceware.org wrote:
Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<cygwin@cygwin.com>:
Mail rejected: List address must be in To: or Cc: headers.
See http://sourceware.org/lists.html#sourceware-list-info for more information.
If you are not a "spammer", we apologize for the inconvenience.
You can add yourself to the cygwin.com "global allow list"
by sending email *from*the*blocked*email*address* to:


-------- Forwarded Message --------
Subject: 	Re: [PATCH] strace: Fix crash caused over-optimization
Date: 	Wed, 19 Apr 2017 10:57:02 -0500
From: 	Daniel Santos <daniel.santos@pobox.com>
To: cygwin-patches@cygwin.com, Corinna Vinschen <corinna-cygwin@cygwin.com>



On 04/18/2017 05:04 AM, Corinna Vinschen wrote:
On Apr 17 03:39, Daniel Santos wrote:

I actually did try that, although I had guessed it wouldn't (and shouldn't)
work.  I believe that the reason is that rather the accesses are volatile or
not, gcc can see nothing else using it and memset can be a treated as a
compiler built-in (per the C spec, maybe C89?), so it can presume the
outcome.  If there's a cleaner way to do this, I would really love to learn
that.  __attribute__ ((used)) only works on variables with static storage.

Now I suspect that I may have found a little bug in gcc, because if I call
memset by casting it directly as a volatile function pointer, it is still
optimized away, and it should not:

   ((void *(*volatile)(void *, int, size_t))memset) (buf, 0, sizeof (buf));

And most interestingly, if I first assign a local volatile function pointer
to the address, then gcc properly does *not* optimize it away:

   void *(*volatile vol_memset)(void *, int, size_t) = memset;
   vol_memset (buf, 0, sizeof (buf));

I'm actually really glad for your response and that I played with this
because I need to make sure that this problem doesn't exist in gcc7.  I have
changes going into gcc8 shortly and this could mask problems from my test
program where I cast functions as volatile w/o assigning using a local.

Daniel
What about using RtlSecureZeroMemory instead?


Corinna

Well that's surprising.  Yes, it does solve the problem and I presume
would be more portable. :)  It even inlines the "memset", but uses a
single byte rep stos.  Technically, I think that a double-word stos
could be used in this case, but I doubt that matters much.

Daniel


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