strlen-avx2.S

[H.J. Lu]

vpxor xmm will clear all upper bits in the register.

On Wed, Jun 19, 2024, 2:39 AM Adhemerval Zanella Netto <
adhemerval.zanella@linaro.org> wrote:

>
>
> On 18/06/24 02:33, David Newall wrote:
> > Hi All,
> >
> > I recently upgraded my PC to one with Intel i9-14900HX, and installed
> Ubuntu22.04.  Since then, remmina (as RDP client) has been periodically
> crashing.  I've tracked it down to a debug statement, which uses the result
> of strlen():
> >
> > REMMINA_PLUGIN_DEBUG("gp=%p returning %zu bytes of text in clipboard to
> requesting application", gp, strlen(clipboard->srv_data));
> >
> > REMMINA_PLUGIN_DEBUG is defined as:
> >
> > remmina_plugin_service->_remmina_debug(__func__, fmt, ##__VA_ARGS__)
> >
> > The core file shows SIGSEG at __strlen_avx2 () at
> ../sysdeps/x86_64/multiarch/strlen-avx2.S:74, called from
> remmina_rdp_cliprdr_request_data(), so the direct call of strlen (i.e. not
> called from _remmina_debug).
> >
> > Clipboard has a reasonable value as does srv_data, which is a generic
> pointer.  Cast to char*, gdb shows the first value as '\0', so strlen()
> should be 0.
> >
> > Libc6 is glibc-2.35 (with Canonical's patches), but
> sysdeps/x86_64/multiarch/strlen-avx2.S (as strlen) is unchanged up to 2.39.
> >
> > Disassembling _strlen_avx2 shows this:
> >
> > Dump of assembler code for function __strlen_avx2:
> >    0x0000758b5c19d7e0 <+0>:    endbr64
> >    0x0000758b5c19d7e4 <+4>:    mov    %edi,%eax
> >    0x0000758b5c19d7e6 <+6>:    mov    %rdi,%rdx
> >    0x0000758b5c19d7e9 <+9>:    vpxor  %xmm0,%xmm0,%xmm0
> >    0x0000758b5c19d7ed <+13>:    and    $0xfff,%eax
> >    0x0000758b5c19d7f2 <+18>:    cmp    $0xfe0,%eax
> >    0x0000758b5c19d7f7 <+23>:    ja     0x758b5c19d930 <__strlen_avx2+336>
> > => 0x0000758b5c19d7fd <+29>:    vpcmpeqb (%rdi),%ymm0,%ymm1
> >    0x0000758b5c19d801 <+33>:    vpmovmskb %ymm1,%eax
> >    0x0000758b5c19d805 <+37>:    test   %eax,%eax
> >    0x0000758b5c19d807 <+39>:    je     0x758b5c19d860 <__strlen_avx2+128>
> >    0x0000758b5c19d809 <+41>:    tzcnt  %eax,%eax
> >    0x0000758b5c19d80d <+45>:    vzeroupper
> >    0x0000758b5c19d810 <+48>:    ret
> >
> > I'm focusing on the instruction causing SIGSEG (marked with "=>"):
> >
> > Do I understand it properly, as comparing memory addressed by RDI with
> YMM0, saving the result in YMM1?
> >
> > YMM0 is 0.  I see where the lower 128-bits were zeroed (by zeroing
> XMM0), but not the upper 128-bits.  What clears them?
> >
> > RDI is 0.  Is this expected?  Am I right that this is why I'm getting
> SIGSEG?
>
> Hi David,
>
> Could you check which is the function argument contents, including the
> memory
> dump of the input pointer? It helps narrow down if it is a possible issue
> with
> the routine or with the caller.
>
> PS: I cced the x86 maintainers.
>