* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
@ 2023-08-26 18:20 ` pinskia at gcc dot gnu.org
2023-08-26 18:21 ` pinskia at gcc dot gnu.org
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-08-26 18:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (which makes me think of register corruption occurring here)
>The codepath is a bit convoluted, setjmp/longjmp are involved.
Which could mean it is a bug in dietlibc's setjmp/longjmp since you said it
works with glibc.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc 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
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-08-26 18:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2023-08-26
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Did you report this to dietlibc too?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc 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
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-26 19:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #3 from Thorsten Glaser <tg at mirbsd dot org> ---
Not yet, given it’s been relatively clearly tracked down to a change in GCC.
I’ll have at its setjmp/longjmp myself now, will report back.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (2 preceding siblings ...)
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
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-26 20:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #4 from Thorsten Glaser <tg at mirbsd dot org> ---
Its {,sig}{set,long}jmp for x32 look good.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (3 preceding siblings ...)
2023-08-26 20:03 ` tg at mirbsd dot org
@ 2023-08-26 20:21 ` tg at mirbsd dot org
2023-08-26 20:49 ` tg at mirbsd dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-26 20:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (4 preceding siblings ...)
2023-08-26 20:21 ` tg at mirbsd dot org
@ 2023-08-26 20:49 ` tg at mirbsd dot org
2023-08-26 21:18 ` tg at mirbsd dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-26 20:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #6 from Thorsten Glaser <tg at mirbsd dot org> ---
dietlibc’s strlen is a horrid SSE nightmare that doesn’t call (f)emms, but it
has a switch global variable __valgrind, if setting that to 1 it uses a very
traditional loop instead, and the registers before/after strlen also match
(only rax has changed), so I’m at a loss.
Changing the line to…
sp += strlen(sp) + 1;
… doesn’t make the problem go away, for some reason. Replacing it with…
while (*sp++) ;
… however *does* make it go away.
I’ll paste a screenlog of single-stepping through the valgrind version of the
code below (http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/.gdbinit?rev=HEAD
has the helpful t macro):
Breakpoint 1, expand (ccp=<optimized out>, wp=wp@entry=0xffffcdf0, f=f@entry=0)
at eval.c:401
401 asm volatile("nop"); //401
(gdb) t
=> 0x40a63f <expand+1875>: nop
402 sp = cstrchr(sp, '\0') + 1;
rax 0xf7ff790e 4160715022
rbx 0x0 0
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xffffcd5c 4294954332
rbp 0xf7ff790c 4160715020
rsp 0xffffcc90 4294954128
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x40a640 4236864
eflags 0x287 [ CF PF SF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x40a640 <expand+1876>: mov ebx,DWORD PTR [rsp+0x48]
0x40a644 <expand+1880>: mov rdi,rbx
0x40a647 <expand+1883>: call 0x42cc7e <strlen>
(gdb) t
=> 0x40a640 <expand+1876>: mov ebx,DWORD PTR [rsp+0x48]
0x0040a644 402 sp = cstrchr(sp, '\0')
+ 1;
rax 0xf7ff790e 4160715022
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xffffcd5c 4294954332
rbp 0xf7ff790c 4160715020
rsp 0xffffcc90 4294954128
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x40a644 4236868
eflags 0x287 [ CF PF SF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x40a644 <expand+1880>: mov rdi,rbx
0x40a647 <expand+1883>: call 0x42cc7e <strlen>
0x40a64c <expand+1888>: mov ecx,DWORD PTR [rsp+0x48]
(gdb) t
=> 0x40a644 <expand+1880>: mov rdi,rbx
0x0040a647 402 sp = cstrchr(sp, '\0')
+ 1;
rax 0xf7ff790e 4160715022
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc90 4294954128
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x40a647 4236871
eflags 0x287 [ CF PF SF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x40a647 <expand+1883>: call 0x42cc7e <strlen>
0x40a64c <expand+1888>: mov ecx,DWORD PTR [rsp+0x48]
0x40a650 <expand+1892>: lea r12d,[rcx+rax*1+0x1]
(gdb) t
=> 0x40a647 <expand+1883>: call 0x42cc7e <strlen>
0x0042cc7e in strlen ()
rax 0xf7ff790e 4160715022
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cc7e 4377726
eflags 0x287 [ CF PF SF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cc7e <strlen>: xor eax,eax
0x42cc80 <strlen+2>: or eax,DWORD PTR [rip+0x74ee] # 0x434174
<__valgrind>
0x42cc86 <strlen+8>: jne 0x42ccca <strlen+76>
(gdb) t
=> 0x42cc7e <strlen>: xor eax,eax
0x0042cc80 in strlen ()
rax 0x0 0
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cc80 4377728
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cc80 <strlen+2>: or eax,DWORD PTR [rip+0x74ee] # 0x434174
<__valgrind>
0x42cc86 <strlen+8>: jne 0x42ccca <strlen+76>
0x42cc88 <strlen+10>: mov rax,rdi
(gdb) t
=> 0x42cc80 <strlen+2>: or eax,DWORD PTR [rip+0x74ee] # 0x434174
<__valgrind>
0x0042cc86 in strlen ()
rax 0x1 1
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cc86 4377734
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cc86 <strlen+8>: jne 0x42ccca <strlen+76>
0x42cc88 <strlen+10>: mov rax,rdi
0x42cc8b <strlen+13>: mov ecx,edi
(gdb) t
=> 0x42cc86 <strlen+8>: jne 0x42ccca <strlen+76>
0x0042ccca in strlen ()
rax 0x1 1
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccca 4377802
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccca <strlen+76>: mov rax,rdi
0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
(gdb) t
=> 0x42ccca <strlen+76>: mov rax,rdi
0x0042cccd in strlen ()
rax 0xf7ff790e 4160715022
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cccd 4377805
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
(gdb) t
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x0042ccd0 in strlen ()
rax 0xf7ff790e 4160715022
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd0 4377808
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
(gdb) t
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x0042ccd2 in strlen ()
rax 0xf7ff790e 4160715022
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd2 4377810
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x42ccd7 <strlen+89>: sub rax,rdi
(gdb) t
=> 0x42ccd2 <strlen+84>: inc rax
0x0042ccd5 in strlen ()
rax 0xf7ff790f 4160715023
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd5 4377813
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x42ccd7 <strlen+89>: sub rax,rdi
0x42ccda <strlen+92>: ret
(gdb) t
=> 0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x0042cccd in strlen ()
rax 0xf7ff790f 4160715023
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cccd 4377805
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
(gdb) t
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x0042ccd0 in strlen ()
rax 0xf7ff790f 4160715023
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd0 4377808
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
(gdb) t
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x0042ccd2 in strlen ()
rax 0xf7ff790f 4160715023
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd2 4377810
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x42ccd7 <strlen+89>: sub rax,rdi
(gdb) t
=> 0x42ccd2 <strlen+84>: inc rax
0x0042ccd5 in strlen ()
rax 0xf7ff7910 4160715024
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd5 4377813
eflags 0x212 [ AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x42ccd7 <strlen+89>: sub rax,rdi
0x42ccda <strlen+92>: ret
(gdb) t
=> 0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x0042cccd in strlen ()
rax 0xf7ff7910 4160715024
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cccd 4377805
eflags 0x212 [ AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
(gdb) t
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x0042ccd0 in strlen ()
rax 0xf7ff7910 4160715024
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd0 4377808
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
(gdb) t
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x0042ccd2 in strlen ()
rax 0xf7ff7910 4160715024
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd2 4377810
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x42ccd7 <strlen+89>: sub rax,rdi
(gdb) t
=> 0x42ccd2 <strlen+84>: inc rax
0x0042ccd5 in strlen ()
rax 0xf7ff7911 4160715025
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd5 4377813
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x42ccd7 <strlen+89>: sub rax,rdi
0x42ccda <strlen+92>: ret
(gdb) t
=> 0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
0x0042cccd in strlen ()
rax 0xf7ff7911 4160715025
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42cccd 4377805
eflags 0x206 [ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
(gdb) t
=> 0x42cccd <strlen+79>: cmp BYTE PTR [rax],0x0
0x0042ccd0 in strlen ()
rax 0xf7ff7911 4160715025
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd0 4377808
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x42ccd2 <strlen+84>: inc rax
0x42ccd5 <strlen+87>: jmp 0x42cccd <strlen+79>
(gdb) t
=> 0x42ccd0 <strlen+82>: je 0x42ccd7 <strlen+89>
0x0042ccd7 in strlen ()
rax 0xf7ff7911 4160715025
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccd7 4377815
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccd7 <strlen+89>: sub rax,rdi
0x42ccda <strlen+92>: ret
0x42ccdb <strncmp>: xor ecx,ecx
(gdb) t
=> 0x42ccd7 <strlen+89>: sub rax,rdi
0x0042ccda in strlen ()
rax 0x3 3
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc88 4294954120
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x42ccda 4377818
eflags 0x216 [ PF AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x42ccda <strlen+92>: ret
0x42ccdb <strncmp>: xor ecx,ecx
0x42ccdd <strncmp+2>: cmp edx,ecx
(gdb) t
=> 0x42ccda <strlen+92>: ret
0x0040a64c in expand (ccp=<optimized out>, wp=wp@entry=0xffffcdf0, f=f@entry=0)
at eval.c:402
402 sp = cstrchr(sp, '\0') + 1;
rax 0x3 3
rbx 0xf7ff790e 4160715022
rcx 0x0 0
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc90 4294954128
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x40a64c 4236876
eflags 0x216 [ PF AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x40a64c <expand+1888>: mov ecx,DWORD PTR [rsp+0x48]
0x40a650 <expand+1892>: lea r12d,[rcx+rax*1+0x1]
0x40a655 <expand+1897>: nop
(gdb) t
=> 0x40a64c <expand+1888>: mov ecx,DWORD PTR [rsp+0x48]
0x0040a650 402 sp = cstrchr(sp, '\0')
+ 1;
rax 0x3 3
rbx 0xf7ff790e 4160715022
rcx 0xf7ff790e 4160715022
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc90 4294954128
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0x2 2
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x40a650 4236880
eflags 0x216 [ PF AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x40a650 <expand+1892>: lea r12d,[rcx+rax*1+0x1]
0x40a655 <expand+1897>: nop
0x40a656 <expand+1898>: movzx ecx,BYTE PTR [ebp+0x2]
(gdb) t
=> 0x40a650 <expand+1892>: lea r12d,[rcx+rax*1+0x1]
405 asm volatile("nop"); //403
rax 0x3 3
rbx 0xf7ff790e 4160715022
rcx 0xf7ff790e 4160715022
rdx 0xffffff81 4294967169
rsi 0x98 152
rdi 0xf7ff790e 4160715022
rbp 0xf7ff790c 4160715020
rsp 0xffffcc90 4294954128
r8 0xa0 160
r9 0x3 3
r10 0x0 0
r11 0x206 518
r12 0xf7ff7912 4160715026
r13 0xffffd1b4 4294955444
r14 0xf7ff510c 4160704780
r15 0x0 0
rip 0x40a655 4236885
eflags 0x216 [ PF AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
=> 0x40a655 <expand+1897>: nop
0x40a656 <expand+1898>: movzx ecx,BYTE PTR [ebp+0x2]
0x40a65b <expand+1903>: test ecx,ecx
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (5 preceding siblings ...)
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
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-26 21:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #7 from Thorsten Glaser <tg at mirbsd dot org> ---
(but with this, I think it’s neither the GCC builtins, nor a change thereof,
nor anything about dietlibc that is at fault; feel free to adjust the title
accordingly)
Surrounding code:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l399
Would gcc-12‑ and ‑13-generated .s files from otherwise identical builds, for
comparison, help? (With -fverbose-asm I presume?) Or anything else?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (6 preceding siblings ...)
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
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-08-28 7:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.3
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Does providing your own (trivially correct) strlen implementation in a separate
CU also fix the issue? That would point towards dietlibc.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (7 preceding siblings ...)
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
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #9 from Thorsten Glaser <tg at mirbsd dot org> ---
> Does providing your own (trivially correct) strlen implementation in a separate CU also fix the issue?
Even providing one that just calls dietlibc’s (in a separate CU) fixes the
issue, so I’m very sure it’s not that, but probably some codegen surrounding
the call.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (8 preceding siblings ...)
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
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 14:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #10 from Thorsten Glaser <tg at mirbsd dot org> ---
oh no, wait, that was for strchr… the strlen one… but, yeah, that too:
extern size_t xstrlen(const char *s);
and changing the line again to…
sp += xstrlen(sp) + 1;
… and adding in another .c file:
size_t xstrlen(const char *s) {
register const char *cp = s;
while (*cp++ != '\0')
;
return (--cp - s);
}
And it still fails.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (9 preceding siblings ...)
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
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 14:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #11 from Thorsten Glaser <tg at mirbsd dot org> ---
OK, to summarise:
When using the original code but providing a wrapper function (in a separate
CU) for strchr, it works.
When replacing the strchr with strlen (which GCC also does), it fails even
without the presence of dietlibc’s strlen. (And yes, disassembly of main.o
(where I added it) shows no call to dietlibc from xstrlen.)
This doesn’t seem to be coupled to the name of the function (the wrapper
functions are called cstrchr and xstrlen, so the compiler cannot make any
assumptions about them).
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (10 preceding siblings ...)
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
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 14:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #12 from Thorsten Glaser <tg at mirbsd dot org> ---
Created attachment 55808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55808&action=edit
tarball (.xz) with preprocessed and assembly output
I’ve verified (back to unmodified source) that it is indeed only the file
eval.c that’s at fault.
I’ve compiled mksh with gcc-12, then built that one file with gcc-13, linked
with gcc-12, and it failed.
I’m attaching an xz-compressed tarball with preprocessed and assembly (both
AT&T and Intel, both -fverbose-asm and not) of the file with exactly identical
options between GCC 12 and 13, in the hope of that being helpful to hunt this
down.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (11 preceding siblings ...)
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
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 15:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #13 from Thorsten Glaser <tg at mirbsd dot org> ---
The interesting part is around the occurrence of…
# eval.c:399: sp = cstrchr(sp, '\0') + 1;
… in the .s files (it occurs thrice, the first is the beginning of the setup
part, the second and third surround the strlen call, so they’re all within a
bunch of lines).
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (12 preceding siblings ...)
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
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2023-08-28 15:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Thorsten Glaser from comment #13)
> The interesting part is around the occurrence of…
>
> # eval.c:399: sp = cstrchr(sp, '\0') + 1;
>
> … in the .s files (it occurs thrice, the first is the beginning of the setup
> part, the second and third surround the strlen call, so they’re all within a
> bunch of lines).
Unfortunately, the runtime bug requires test that fails at runtime; the
attached dumps are not that usable. The fact that the compiler fails for not so
common target makes things even harder.
I think that the best way forward is to create a minimized standalone testcase
(From Comment #11 it looks that the issue is independent of dietlibc) that can
be compiled with -mx32 in a kind of cross-compiler fashion. You can use
-maddress-mode=long with -mx32 to create a .s assembly file that is compatible
with x86_64, as far as stack handling is concerned.
The resulting .s assembly can then be compiled and linked with a C wrapper, so
a testcase that eventually fails on x86_64 can be produced.
IOW, does the testcase fail when -maddress-mode=long is used?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (13 preceding siblings ...)
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
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: hjl.tools at gmail dot com @ 2023-08-28 15:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
We need a testcase which can be reproduced with glibc since the bug may be in
other parts of dietlibc.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (14 preceding siblings ...)
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
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 16:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #16 from Thorsten Glaser <tg at mirbsd dot org> ---
If I add -maddress-mode=long to the build of the expr.c file, then link it with
the rest, it still fails.
I’m not sure about reducing, and not sure about the cross-anything, but I *did*
get it to fail on amd64 now! (Just differently.) HOWEVER, I’m not sure whether
this is from x32/amd64 mismatch or from the bug, as the resulting pattern
differs.
The code flow is roughly: eval.c from line 1608 onwards opens a temporary file,
dups it to stdout, calls funsub() from line 2147, and on return rewinds that
file and restores stdout. This all is called from line 352 (where the jump to
the subroutine is), but the strlen in question is on line 399 in a different
codepath (where the stuff immediately following '${' is parsed). They only have
the use of the variable 'sp' and the jumping past the first NUL in it in common
(the funsub caller has 'sp = strnul(sp) + 1;' instead, but that’s just
'sp+strlen(sp)', and changing the 'sp = cstrchr(sp, '\0') + 1;' to that (which
I did in upstream CVS HEAD now anyway) doesn’t “fix” the issue.
In a Debian sid/amd64 chroot, with GCC 13.2.0-1 (as packaged in Debian), I did:
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -I. -D_FORTIFY_SOURCE=2
-DMKSH_BUILDMEAT -DMKSH_BUILDSH=1 -D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN=1
-DHAVE_STRING_POOLING=2 -DHAVE_ATTRIBUTE_BOUNDED=0 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_SELECT_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1
-DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_PTEM_H=0 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SYSMACROS_H=1
-DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_IO_H=0 -DHAVE_LIBGEN_H=1
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -DHAVE_CAN_INTTYPES=1
-DHAVE_SIG_T=1 -DHAVE_STRERRORDESC_NP=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_SIGABBREV_NP=1 -DHAVE_SYS_SIGNAME=0 -DHAVE_SIGDESCR_NP=1
-DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1 -DHAVE_LOCK_FCNTL=1 -DHAVE_RLIMIT=1
-DHAVE_RLIM_T=1 -DHAVE_GET_CURRENT_DIR_NAME=1 -DHAVE_GETRANDOM=0
-DHAVE_GETRUSAGE=1 -DHAVE_GETSID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_FTRUNCATE=1 -DHAVE_NICE=1
-DHAVE_RENAME=1 -DHAVE_REVOKE=0 -DHAVE_POSIX_UTF8_LOCALE=0 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_SIGACTION=1 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=0 -DHAVE_STRSTR=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1
-DHAVE_ST_MTIMENSEC=0 -DHAVE_INTCONSTEXPR_RSIZE_MAX=0
-DHAVE_PERSISTENT_HISTORY=1 -DMKSH_BUILD_R=599 -c lalloc.c edit.c eval.c exec.c
expr.c funcs.c histrap.c jobs.c lex.c main.c misc.c shf.c syn.c tree.c var.c
ulimit.c strlcpy.c
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -fno-lto -o mksh lalloc.o
edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o
syn.o tree.o var.o ulimit.o strlcpy.o
./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -I. -D_FORTIFY_SOURCE=2
-DMKSH_BUILDMEAT -DMKSH_BUILDSH=1 -D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN=1
-DHAVE_STRING_POOLING=2 -DHAVE_ATTRIBUTE_BOUNDED=0 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_SELECT_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1
-DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_PTEM_H=0 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SYSMACROS_H=1
-DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_IO_H=0 -DHAVE_LIBGEN_H=1
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -DHAVE_CAN_INTTYPES=1
-DHAVE_SIG_T=1 -DHAVE_STRERRORDESC_NP=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_SIGABBREV_NP=1 -DHAVE_SYS_SIGNAME=0 -DHAVE_SIGDESCR_NP=1
-DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1 -DHAVE_LOCK_FCNTL=1 -DHAVE_RLIMIT=1
-DHAVE_RLIM_T=1 -DHAVE_GET_CURRENT_DIR_NAME=1 -DHAVE_GETRANDOM=0
-DHAVE_GETRUSAGE=1 -DHAVE_GETSID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_FTRUNCATE=1 -DHAVE_NICE=1
-DHAVE_RENAME=1 -DHAVE_REVOKE=0 -DHAVE_POSIX_UTF8_LOCALE=0 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_SIGACTION=1 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=0 -DHAVE_STRSTR=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1
-DHAVE_ST_MTIMENSEC=0 -DHAVE_INTCONSTEXPR_RSIZE_MAX=0
-DHAVE_PERSISTENT_HISTORY=1 -DMKSH_BUILD_R=599 -c -o eval.o eval-13.i
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -fno-lto -o mksh lalloc.o
edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o
syn.o tree.o var.o ulimit.o strlcpy.o
./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'
So basically, I first compiled all the files, but with the options from the
dietlibc build (modulo signames[]), against glibc, linked it, and verified it
works (output “.a.”).
Then I built the .i file from the preprocessed output of the x32 dietlibc build
with the same options, for amd64, linked and ran it, and it did not give the
exact identical bogus output, but first “a” on a line by itself, then “..”.
Then I installed the Debian packages linux-libc-dev-x32-cross
libc6-dev-x32-cross and preprocessed under x32 and built that on amd64…
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -I. -D_FORTIFY_SOURCE=2
-DMKSH_BUILDMEAT -DMKSH_BUILDSH=1 -D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN=1
-DHAVE_STRING_POOLING=2 -DHAVE_ATTRIBUTE_BOUNDED=0 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_SELECT_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1
-DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_PTEM_H=0 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SYSMACROS_H=1
-DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_IO_H=0 -DHAVE_LIBGEN_H=1
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -DHAVE_CAN_INTTYPES=1
-DHAVE_SIG_T=1 -DHAVE_STRERRORDESC_NP=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_SIGABBREV_NP=1 -DHAVE_SYS_SIGNAME=0 -DHAVE_SIGDESCR_NP=1
-DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1 -DHAVE_LOCK_FCNTL=1 -DHAVE_RLIMIT=1
-DHAVE_RLIM_T=1 -DHAVE_GET_CURRENT_DIR_NAME=1 -DHAVE_GETRANDOM=0
-DHAVE_GETRUSAGE=1 -DHAVE_GETSID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_FTRUNCATE=1 -DHAVE_NICE=1
-DHAVE_RENAME=1 -DHAVE_REVOKE=0 -DHAVE_POSIX_UTF8_LOCALE=0 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_SIGACTION=1 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=0 -DHAVE_STRSTR=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1
-DHAVE_ST_MTIMENSEC=0 -DHAVE_INTCONSTEXPR_RSIZE_MAX=0
-DHAVE_PERSISTENT_HISTORY=1 -DMKSH_BUILD_R=599 -mx32 -E -o x.i eval.c
-I/usr/x86_64-linux-gnux32/include
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -I. -D_FORTIFY_SOURCE=2
-DMKSH_BUILDMEAT -DMKSH_BUILDSH=1 -D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN=1
-DHAVE_STRING_POOLING=2 -DHAVE_ATTRIBUTE_BOUNDED=0 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_SELECT_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1
-DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_PTEM_H=0 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SYSMACROS_H=1
-DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_IO_H=0 -DHAVE_LIBGEN_H=1
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -DHAVE_CAN_INTTYPES=1
-DHAVE_SIG_T=1 -DHAVE_STRERRORDESC_NP=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_SIGABBREV_NP=1 -DHAVE_SYS_SIGNAME=0 -DHAVE_SIGDESCR_NP=1
-DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1 -DHAVE_LOCK_FCNTL=1 -DHAVE_RLIMIT=1
-DHAVE_RLIM_T=1 -DHAVE_GET_CURRENT_DIR_NAME=1 -DHAVE_GETRANDOM=0
-DHAVE_GETRUSAGE=1 -DHAVE_GETSID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_FTRUNCATE=1 -DHAVE_NICE=1
-DHAVE_RENAME=1 -DHAVE_REVOKE=0 -DHAVE_POSIX_UTF8_LOCALE=0 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_SIGACTION=1 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=0 -DHAVE_STRSTR=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1
-DHAVE_ST_MTIMENSEC=0 -DHAVE_INTCONSTEXPR_RSIZE_MAX=0
-DHAVE_PERSISTENT_HISTORY=1 -DMKSH_BUILD_R=599 -c -o eval.o x.i
… and got the same result.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (15 preceding siblings ...)
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
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 16:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #17 from Thorsten Glaser <tg at mirbsd dot org> ---
Hm, okay, I’ll try to find if I can trigger it in glibc/x32 then…
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (16 preceding siblings ...)
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
18 siblings, 0 replies; 20+ messages in thread
From: tg at mirbsd dot org @ 2023-08-28 16:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
--- Comment #18 from Thorsten Glaser <tg at mirbsd dot org> ---
I cannot, unfortunately. But I have found _another_ “mitigation”:
varsub() is static and has only one caller:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l400
By making varsub…
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l1238
… not static, the bug *also* goes away. (Probably because varsub is not
inlined.)
Now we see that…
399 sp = cstrchr(sp, '\0') + 1;
400 type = varsub(&x, varname, sp, &stype,
&slen);
… the varsub call is *directly* below the strchr/strlen line, *and* it gets
passed the sp variable. (Inside varsub, the variable is also modified.)
My suspicion here is that, somehow only triggerable on x32+dietlibc, something
about the multiple modifications of sp (just before and within varsub) confuses
GCC?
And indeed. Adding -O2, -O1, -O0 to the GCC command line doesn’t help, but
-fno-inline again does.
As does adding an attribute to the function prototype:
static int varsub(Expand *, const char *, const char *, unsigned int *, int *)
__attribute__((noinline));
Could we somehow debug there further? I really don’t see a way to reproduce
this on x32/glibc or amd64…
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
2023-08-26 18:17 [Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc tg at mirbsd dot org
` (17 preceding siblings ...)
2023-08-28 16:38 ` tg at mirbsd dot org
@ 2024-05-21 9:16 ` jakub at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 9:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111165
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|13.3 |13.4
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.
^ permalink raw reply [flat|nested] 20+ messages in thread