V2: [PATCH] x32: Generate 0x67 prefix for VSIB address without base

[Jan Beulich]

>>> On 26.02.19 at 17:07, <hjl.tools@gmail.com> wrote:
> On Tue, Feb 26, 2019 at 6:45 AM Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >>> On 26.02.19 at 14:23, <hjl.tools@gmail.com> wrote:
>> > On Tue, Feb 26, 2019 at 3:41 AM Jan Beulich <JBeulich@suse.com> wrote:
>> >>
>> >> >>> On 26.02.19 at 05:35, <hjl.tools@gmail.com> wrote:
>> >> > In x32, add ADDR_PREFIX_OPCODE prefix for VSIB address without base
>> >> > register so that vector index register will be zero-extended to 64 bits.
>> >> >
>> >> > We can't have ADDR_PREFIX_OPCODE prefix with 32-bit address if there is
>> >> > segment override since address will be segment base + zero-extended to 64
>> >> > bits of (base + index * scale + disp).  But GCC:
>> >> >
>> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502 
>> >>
>> >> Neither above nor in the bug you explain what's wrong with the
>> >> segment override plus address size override in x32 mode. Since you
>> >
>> > X32 relies on 0x67 prefix to zero-extend address to 64 bits:
>> >
>> > zero-extended (base + index * scale + disp)
>> >
>> > With segment override, we got
>> >
>> > segment base + zero-extended (base + index * scale + disp)
>> >
>> > instead of
>> >
>> > zero-extended (segment base + base + index * scale + disp)
>> >
>> > When base + index * scale + disp is negative, we get the wrong
>> > address.
>> >
>> > VSIB address in vgatherdps is
>> >
>> > base + sign-extend(index) * scale + disp
>> >
>> > With segment override, we got
>> >
>> > segment base + zero-extended (base + sign-extend(index) * scale + disp)
>>
>> Right. But whether that's what the programmer wanted we don't
>> know. Also please consider the qword index forms as well, plus
>> the dword index forms with scaling factor 2, 4, or 8 (allowing for
>> effective indexes up to 35 bits wide).
>>
>> All of this would be acceptable if address space was limited to 4Gb
>> for x32, but that's not the case according to my reading of the
>> chapter in the psABI.
> 
> 10.4 Kernel Support
> Kernel should limit stack and addresses returned from system calls
> bewteen 0x00000000
> to 0xf f f f f f f f .

Hmm, if that's indeed the case, despite it - according to my
interpretation - contradicting 10.2's wording, and despite it
being an unnecessary restriction imo, then ...

>> > 175.vpr in SPEC CPU 2000:
>> >[...]
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0x004158fd in try_place.isra ()
>> > (gdb) disass 0x004158fd,+32
>> > Dump of assembler code from 0x4158fd to 0x41591d:
>> > => 0x004158fd <try_place.isra.5+7517>: vgatherdps %ymm2,0xc(,%ymm15,1),%ymm12
>>
>> Okay, this is the special case of the index register actually holding
>> addresses. What about the case where the displacement is the base
>> address, and the index register holds indeed indexes?
> 
> I will fix it.

... there's nothing to fix here, I think.

Jan