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.
