<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 12/23/2017 01:56 PM, Juneyoung Lee
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAGwnbJSrXW_gjoEjxjzcKej2fX3QMwZaKaPNWaYZr35eus9FpQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div>
<div>
<div>Hello.</div>
<div>This might be a trivial question, but is it correct if
the signal handler aborts the program?</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, because the actions of SEGSEGV signal handlers don't fall
within the abstract machine we're modeling. If they did, we'd need
to treat all volatile memory accesses as arbitrary function calls
(because that's exactly what they'd be). This would inhibit our
ability to do almost any kind of pointer-aliasing reasoning about
the volatile accesses (i.e., they'd alias with anything that might
be visible to an external function), and moreover, they'd all be
read/write (because that external function might do anything).<br>
<br>
Another way to look at this is: Once the SEGSEGV is generated, the
program has already triggered UB (regardless of whether the access
is volatile and regardless of what the handler might do). This UB is
just as undefined as any other.<br>
<br>
When we've discussed this in the past, I believe the recommendation
was that, if we want to support a mode in which volatile accesses
have these kinds of semantics (and there are certainly environments
in which this might make sense), then we should have Clang lower
them into some kind of "volatile-access intrinsics" because it will
be easy to make these look like arbitrary read/write function calls
in the optimizer.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAGwnbJSrXW_gjoEjxjzcKej2fX3QMwZaKaPNWaYZr35eus9FpQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>For example:</div>
<div><br>
</div>
<div> int *normal = ADDRESS1;</div>
<div> volatile int* ptr = ADDRESS2;</div>
<div> int k = *ptr; // segfaults, and the signal handler
calls abort()</div>
<div> int value = *normal; // this may be UB(undefined
behavior).</div>
<div><br>
</div>
<div>Let's assume that normal is dereferenceable if ptr1
does not raise SEGSEGV, but accessing normal raises UB if
ptr1 raises SEGSEGV.</div>
<div>Before reordering is done, there's no UB because the
program will always abort if UB could happen, but UB may
happen after they are reordered.</div>
<div><br>
</div>
</div>
</div>
<div>Best Regards,</div>
<div>Juneyoung Lee</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 21, 2017 at 4:50 AM,
Krzysztof Parzyszek via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 12/20/2017 1:37 PM, Sanjoy Das wrote:><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Fwiw, I was under the impression that regular loads
could *not* be<br>
reordered with volatile loads since we could have e.g.:<br>
<br>
int *normal = &global_variable;<br>
volatile int* ptr = 0;<br>
int k = *ptr; // segfaults, and the signal handler
writes to *normal<br>
int value = *normal;<br>
<br>
and that we'd have to treat volatile loads and stores
essentially as<br>
calls to unknown functions.<br>
</blockquote>
<br>
</span>
For this to work, "normal" should be volatile as well.<br>
<br>
-Krzysztof<span class="im HOEnZb"><br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation<br>
</span>
<div class="HOEnZb">
<div class="h5">
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div><br>
</div>
<font size="1">Juneyoung Lee</font>
<div><font size="1">Software Foundation Lab, Seoul National
University</font></div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>