Re: Possible bug in valgrind uninitialized variable detection (negative array index)

At 2021-11-10 01:18Z, Kyryl Melekhin wrote:
> Ok, stop. I forgot, the executables likely won't work because my MuslC was
> -march native optimized. And obviously static linking will include that code.

Whn I look at this file:
     $ ls -l piketcc  # compiled by tcc
     -rwxr-xr-x. 1 user group 80208 Nov 10 20:38Z  piketcc
     $ sha256sum piketcc
     6579786352c53de2fc8dc8322b866256870b911fc1b700202889b6fee9a45ff4  piketcc

disassembled by gdb, and next examined in a text editor, then I see
curious manipulation of the stack pointer %rsp:

Dump of assembler code for function re_pikevm:  [VLA = Variable-Length Array]
:g/%rsp,/p   ## direct reads of the stack pointer
    0x000000000040235f <+1>:     mov    %rsp,%rbp  # Frame pointer at entry
    0x00000000004023e1 <+131>:   mov    %rsp,-0x88(%rbp)  # remember the address of a VLA
    0x00000000004023f2 <+148>:   mov    %rsp,-0x80(%rbp)
    0x0000000000402416 <+184>:   mov    %rsp,-0x98(%rbp)
    0x000000000040243d <+223>:   mov    %rsp,-0xa8(%rbp)
    0x0000000000402489 <+299>:   mov    %rsp,-0x7a1f8(%rbp)
    0x00000000004024b3 <+341>:   mov    %rsp,-0x7a208(%rbp)

:g/,%rsp/p   ## writes to the stack pointer
    0x0000000000402362 <+4>:     sub    $0x7a240,%rsp  # allocate fixed portion of stack frame
    0x00000000004023eb <+141>:   sub    %rax,%rsp  # allocate a VLA: %rsp -= %rax
    0x00000000004023ee <+144>:   and    $0xfffffffffffffff0,%rsp  # 16-byte align a VLA
    0x000000000040240f <+177>:   sub    %rax,%rsp
    0x0000000000402412 <+180>:   and    $0xfffffffffffffff0,%rsp
    0x0000000000402436 <+216>:   sub    %rax,%rsp
    0x0000000000402439 <+219>:   and    $0xfffffffffffffff0,%rsp
    0x0000000000402482 <+292>:   sub    %rax,%rsp
    0x0000000000402485 <+295>:   and    $0xfffffffffffffff0,%rsp
    0x00000000004024ac <+334>:   sub    %rax,%rsp
    0x00000000004024af <+337>:   and    $0xfffffffffffffff0,%rsp
    0x00000000004024fa <+412>:   mov    -0x88(%rbp),%rsp
    0x00000000004026c4 <+870>:   mov    -0x7a208(%rbp),%rsp
    0x00000000004026ec <+910>:   mov    -0x7a208(%rbp),%rsp
    0x00000000004026f3 <+917>:   mov    -0x7a208(%rbp),%rsp
    0x000000000040272c <+974>:   mov    -0x7a208(%rbp),%rsp
    0x000000000040278d <+1071>:  mov    -0x7a208(%rbp),%rsp
    0x00000000004027de <+1152>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402e3e <+2784>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402e8c <+2862>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402f63 <+3077>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000402fbc <+3166>:  mov    -0x7a208(%rbp),%rsp
    0x000000000040309c <+3390>:  mov    -0x7a208(%rbp),%rsp
    0x00000000004030fd <+3487>:  mov    -0x7a208(%rbp),%rsp
    0x000000000040314e <+3568>:  mov    -0x7a208(%rbp),%rsp
    0x0000000000403683 <+4901>:  mov    -0x88(%rbp),%rsp
    0x0000000000403813 <+5301>:  mov    -0x88(%rbp),%rsp
    0x0000000000403824 <+5318>:  mov    -0x88(%rbp),%rsp


When run with command-line arguments "./piketcc abc abc", then examination
of all the "mov -0x7a208(%rbp),%rsp" instructions shows that the value
in register %rsp does not change.  I wonder if valgrind does something
strange here, such as marking some portion of the fixed frame as uninit
even though nothing changes.

The corresponding pikegcc never re-loads %rsp after allocating the VLAs:
     $ ls -l pikegcc
     -rwxr-xr-x. 1 user group 72960 Nov 10 20:37Z pikegcc
     $ sha256sum pikegcc
     952ce60eb5f66445f08d8ffc14b348febdefc99f4985cd4e725ae3d1682246c8  pikegcc

:g/%rsp,/p  # direct reads of stack pointer %rsp
    0x40328d <re_pikevm+1>:      mov    %rsp,%rbp
    0x000000000040328d <+1>:     mov    %rsp,%rbp
    0x00000000004032ca <+62>:    mov    %rsp,%rax
    0x0000000000403395 <+265>:   mov    %rsp,%rax
    0x0000000000403406 <+378>:   mov    %rsp,%rax
    0x0000000000403489 <+509>:   mov    %rsp,%rax
    0x0000000000403523 <+663>:   mov    %rsp,%rax
    0x00000000004035a7 <+795>:   mov    %rsp,%rax
:g/,%rsp/p  # writes to register %rsp
    0x403299 <re_pikevm+13>:     sub    $0x7a298,%rsp
    0x0000000000403299 <+13>:    sub    $0x7a298,%rsp
    0x0000000000403392 <+262>:   sub    %rax,%rsp  # allocate VLA; %rax is pre-aligned to (0 mod 16)
    0x0000000000403403 <+375>:   sub    %rax,%rsp
    0x0000000000403486 <+506>:   sub    %rax,%rsp
    0x0000000000403520 <+660>:   sub    %rax,%rsp
    0x00000000004035a4 <+792>:   sub    %rax,%rsp
    0x0000000000404956 <+5834>:  mov    %rbx,%rsp
    0x000000000040496d <+5857>:  lea    -0x28(%rbp),%rsp  # begin subroutine epilog

Investigation continues...