This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x32: Generate 0x67 prefix for VSIB address without base
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 25 Feb 2019 08:14:20 -0700
- Subject: Re: [PATCH] x32: Generate 0x67 prefix for VSIB address without base
- References: <20190225140212.7737-1-hjl.tools@gmail.com>
>>> On 25.02.19 at 15:02, <hjl.tools@gmail.com> wrote:
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -8194,6 +8194,32 @@ output_insn (void)
> }
> else
> {
> +#if defined (OBJ_MAYBE_ELF) || defined (OBJ_ELF)
> + if (x86_elf_abi == X86_64_X32_ABI
> + && i.tm.opcode_modifier.vecsib)
> + {
> + /* In x32, add ADDR_PREFIX_OPCODE prefix for VSIB address
> + without base register so that vector index register
> + won't be sign-extended to 64 bits. */
> + if (!i.base_reg)
> + add_prefix (ADDR_PREFIX_OPCODE);
Leaving aside the question of how one would go about overriding
this behavior (after all iirc it's not forbidden to use full 64-bit
addresses / base registers in x32) I understand this part, but ...
> + /* In x32, we can't have ADDR_PREFIX_OPCODE prefix for
> + VSIB if there is segment override since address will
> + be segment override + zero-extended to 64 bits of
> + (base + index * scale + disp). */
... I don't understand this: What is it that goes wrong here in
x32 mode? "base" is either zero or a full 64-bit value anyway, so
I'm struggling in the first place what (uniform) zero-extension the
comment is talking about. But I also don't understand why, if this
was needed at all, it would affect VSIB addressing only.
Also indentation looks inconsistent here (tabs vs spaces).
> + if (i.prefix[ADDR_PREFIX] && i.prefix[SEG_PREFIX])
> + {
> + const seg_entry *seg;
> + if (i.seg[0])
> + seg = i.seg[0];
> + else
> + seg = i.seg[1];
> + as_bad (_("can't encode segment `%s' with 32-bit VSIB"),
> + seg->seg_name);
Please don't emit the % prefix unconditionally, it should not be there
in no-prefix / Intel mode.
Jan