From: "Mihai Donțu" <mdontu@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Cc: "Wei Liu" <wei.liu2@citrix.com>,
"Jan Beulich" <JBeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] libx86: Work around GCC bug with ebx output constrants
Date: Mon, 19 Nov 2018 16:52:25 +0200 [thread overview]
Message-ID: <1542639145.26770.14.camel@bitdefender.com> (raw)
In-Reply-To: <f0b3c2fb-8d31-7e79-c666-4d5b8d7153eb@citrix.com>
On Mon, 2018-11-19 at 13:29 +0000, Andrew Cooper wrote:
> On 19/11/2018 13:11, Andrew Cooper wrote:
> > Some versions of GCC can't compile cpuid.c, and fail with the rather cryptic:
> >
> > In file included from lib/x86/cpuid.c:3:0:
> > lib/x86/cpuid.c: In function ‘x86_cpuid_policy_fill_native’:
> > include/xen/lib/x86/cpuid.h:25:5: error: inconsistent operand constraints in an ‘asm’
> > asm ( "cpuid"
> > ^
> >
> > In practice, this is a collision between the output constraint and the GOT
> > which is held in %ebx when compiling with -fPIC for libraries.
> >
> > This affects at least GCC 4.9 as shipped in Debian Jessie, but experimentally
> > is fixed in GCC 6 and later. Curiously, it only affects 32-bit builds.
>
> Actually, having just got GCC 5 working, that is also fine. I'll adjust
> the wording/check, but won't bother posting a v2 if that is the only change.
I wonder if it has anything to do with this:
"Reuse of the PIC hard register, instead of using a fixed register, was
implemented on x86/x86-64 targets. This improves generated PIC code
performance as more hard registers can be used. Shared libraries can
significantly benefit from this optimization. Currently it is switched
on only for x86/x86-64 targets. As RA infrastructure is already
implemented for PIC register reuse, other targets might follow this in
the future."
https://gcc.gnu.org/gcc-5/changes.html
--
Mihai Donțu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-11-19 14:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 13:11 [PATCH] libx86: Work around GCC bug with ebx output constrants Andrew Cooper
2018-11-19 13:29 ` Andrew Cooper
2018-11-19 14:52 ` Mihai Donțu [this message]
2018-11-19 15:00 ` Andrew Cooper
2018-11-19 13:51 ` Jan Beulich
2018-11-19 14:08 ` Andrew Cooper
2018-11-19 14:21 ` Jan Beulich
2018-11-19 14:23 ` Jan Beulich
2018-11-19 14:24 ` Andrew Cooper
2018-11-19 14:33 ` Andrew Cooper
2018-11-19 14:38 ` Jan Beulich
2018-11-19 14:45 ` [PATCH v2] " Andrew Cooper
2018-11-19 15:14 ` Jan Beulich
2018-11-19 15:19 ` Andrew Cooper
2018-11-19 15:30 ` Jan Beulich
2018-11-19 15:13 ` [PATCH v3] libx86: Work around GCC being unable to spill the PIC hard register Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1542639145.26770.14.camel@bitdefender.com \
--to=mdontu@bitdefender.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).