public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tg at mirbsd dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
Date: Sat, 26 Aug 2023 20:21:23 +0000	[thread overview]
Message-ID: <bug-111165-4-5aZgt8Fqfk@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111165-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165

--- Comment #5 from Thorsten Glaser <tg at mirbsd dot org> ---
I managed to isolate one specific strchr call changing which causes the
breakage to go away:

    asm volatile("nop"); //401
                                sp = cstrchr(sp, '\0') + 1;
    asm volatile("nop"); //403

where:

#define cstrchr(s,c)    ((const char *)strchr((s), (c)))

        const char *sp;

I inserted NOPs around (see above) and set gdb breakpoints there, and
before/after those breakpoints, the callee-saved registers differ (only showing
callee-saved registers for amd64/x32):

(gdb) info r
rbx            0x0                 0
rbp            0xf7ff790c          4160715020
r12            0x2                 2
r13            0xffffd1b4          4294955444
r14            0xf7ff510c          4160704780
r15            0x0                 0
(gdb) c
(gdb) info r
rbx            0xf7ff790e          4160715022
rbp            0xf7ff790c          4160715020
r12            0xf7ff7912          4160715026
r13            0xffffd1b4          4294955444
r14            0xf7ff510c          4160704780
r15            0x0                 0

Corresponding disassembly of generated code between the NOPs:

=> 0x0040a635 <+1875>:  nop
   0x0040a636 <+1876>:  mov    0x48(%rsp),%ebx
   0x0040a63a <+1880>:  mov    %rbx,%rdi
   0x0040a63d <+1883>:  call   0x42cc6e <strlen>
   0x0040a642 <+1888>:  mov    0x48(%rsp),%ecx
   0x0040a646 <+1892>:  lea    0x1(%rcx,%rax,1),%r12d
   0x0040a64b <+1897>:  nop

or, in readable:

=> 0x0040a635 <+1875>:  nop
   0x0040a636 <+1876>:  mov    ebx,DWORD PTR [rsp+0x48]
   0x0040a63a <+1880>:  mov    rdi,rbx
   0x0040a63d <+1883>:  call   0x42cc6e <strlen>
   0x0040a642 <+1888>:  mov    ecx,DWORD PTR [rsp+0x48]
   0x0040a646 <+1892>:  lea    r12d,[rcx+rax*1+0x1]
   0x0040a64b <+1897>:  nop

OK, huh… no strchr involved here.

For comparison, with -fno-builtin-strchr:

=> 0x0040a632 <+1872>:  nop
   0x0040a633 <+1873>:  mov    ebx,DWORD PTR [rsp+0x48]
   0x0040a637 <+1877>:  xor    esi,esi
   0x0040a639 <+1879>:  mov    rdi,rbx
   0x0040a63c <+1882>:  call   0x42cba4 <strchr>
   0x0040a641 <+1887>:  mov    r14d,eax
   0x0040a644 <+1890>:  inc    eax
   0x0040a646 <+1892>:  mov    DWORD PTR [rsp+0x3c],eax
   0x0040a64a <+1896>:  nop

I’ll dig into strlen in dietlibc/x32 next.

  parent reply	other threads:[~2023-08-26 20:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26 18:17 [Bug target/111165] New: " tg at mirbsd dot org
2023-08-26 18:20 ` [Bug target/111165] " pinskia at gcc dot gnu.org
2023-08-26 18:21 ` pinskia at gcc dot gnu.org
2023-08-26 19:36 ` tg at mirbsd dot org
2023-08-26 20:03 ` tg at mirbsd dot org
2023-08-26 20:21 ` tg at mirbsd dot org [this message]
2023-08-26 20:49 ` tg at mirbsd dot org
2023-08-26 21:18 ` tg at mirbsd dot org
2023-08-28  7:25 ` rguenth at gcc dot gnu.org
2023-08-28 14:22 ` tg at mirbsd dot org
2023-08-28 14:41 ` tg at mirbsd dot org
2023-08-28 14:46 ` tg at mirbsd dot org
2023-08-28 14:57 ` tg at mirbsd dot org
2023-08-28 15:02 ` tg at mirbsd dot org
2023-08-28 15:26 ` ubizjak at gmail dot com
2023-08-28 15:44 ` hjl.tools at gmail dot com
2023-08-28 16:08 ` tg at mirbsd dot org
2023-08-28 16:09 ` tg at mirbsd dot org
2023-08-28 16:38 ` tg at mirbsd dot org
2024-05-21  9:16 ` jakub at gcc dot gnu.org

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=bug-111165-4-5aZgt8Fqfk@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).