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...
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
