This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] x86: Apply standalone prefixes to the following instruction
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at suse dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 19 Jul 2019 08:01:01 -0700
- Subject: Re: [PATCH] x86: Apply standalone prefixes to the following instruction
- References: <CAMe9rOohqV49DVBVRr_kNTyT6ruNYJZgTCWkq4B-Bmh+VRAM=Q@mail.gmail.com> <firstname.lastname@example.org>
On Fri, Jul 19, 2019 at 1:46 AM Jan Beulich <JBeulich@suse.com> wrote:
> On 19.07.2019 00:26, H.J. Lu wrote:
> > Standalone prefixes should be applied to the following instruction,
> > instead of being treated as regular instructions. An error should be
> > issued when a standalone prefix is at the end of source or isn't
> > followed by an instruction in the same section.
> Commenting here, because commenting on the actual code fragments is
> not easily possible with the patch sent as attachment.
> For one, I don't agree that errors should be issued when switching
> sections. Clever assembly programming can easily result in the
> actual section later getting resumed, and an appropriate insn being
Yes, you will get an error which can be easily fixed.
> And then I'm getting the impression that the change here is going
> to break things like
> static inline unsigned int find_first_set_bit(unsigned long word)
> asm ( "rep; bsf %1,%0" : "=r" (word) : "rm" (word) );
> return (unsigned int)word;
"rep; bsf" works like "rep bsf".
> (quoted from Xen sources), being a backwards compatible
> representation of tzcnt. Just like such have shown up in the past,
> REP prefixes could easily obtain meaning for other insns going
> forward, so tagging individual templates with RepPrefixOk is not
> going to help. WBNOINVD is a pretty recent example.
Since adding REP to random instructions may lead to different instructions,
RepPrefixOk is used to prevent that. If one really wants different
".byte 0xf3" can be used.