<html>
<head>
<base href="https://bugzilla.icculus.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - vm_x86.c inline assembly error on hosts using -fPIC"
href="https://bugzilla.icculus.org/show_bug.cgi?id=6429#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - vm_x86.c inline assembly error on hosts using -fPIC"
href="https://bugzilla.icculus.org/show_bug.cgi?id=6429">bug 6429</a>
from <span class="vcard"><a class="email" href="mailto:mark@noffle.net" title="Mark <mark@noffle.net>"> <span class="fn">Mark</span></a>
</span></b>
<pre>Sadly, no go with the most recent push. Same error in impossible constraint
violation with gcc 4.9.3.
That said, shortly before you pushed your latest commit I had modified the
assembly to pretty much what you had:
"mov %%ebx, %2\n"
and compiled the resulting code with gcc 6.1.0 which resulted in the binary
being compiled properly. In this case once the binary was compiled with all the
object files using -fPIC (including vm_x86.c) with no errors, I enabled -pie on
the linker to finalize the process.
Once I confirmed that was working, additional hardening compiler flags were set
with gcc 6.1.0 and the binary was copied over to the hardened host which had no
issues with the binary.
Interesting that the compiler constraint error occurs with gcc 4.9.3 but is
fine with 6.1.0. a 2016-03 gcc post
(<a href="https://gcc.gnu.org/ml/gcc-help/2016-03/msg00156.html">https://gcc.gnu.org/ml/gcc-help/2016-03/msg00156.html</a>) suggests that EBX was
considered reserved on i686 when generating PIC code but was changed to no
longer be reserved as of gcc 5. I guess it's possible gcc 4 considers all usage
of ebx in inline assembly, regardless of manually saving and restoring ebx, as
violating the reservation when -fPIC is enabled?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>