Re: Changes to stat ABI

On 5/15/22 17:31, Warner Losh wrote:
> Scratch that, this is a clang 11 vs clang13 issue.
>
> Most likely clang 13 is more aggressively optimizing, so fstat is not 
> actually on the stack... Because
> of LTO, you'll need to check the disassembled binary to know for sure.
>

It makes no difference which compiler I use, same results either way.

The disassembler is slightly different

clang 11 / FreeBSD 13

   201ba1:       8b bd b4 f6 ff ff       mov    -0x94c(%rbp),%edi
   201ba7:       48 8d b5 d0 f6 ff ff    lea    -0x930(%rbp),%rsi
   201bae:       89 85 a4 f6 ff ff       mov    %eax,-0x95c(%rbp)
   201bb4:       e8 f7 00 00 00          call   201cb0 <fstatfs@plt>

clang 13 / FreeBSD 13.1

   201b8d:       8b bd b4 f6 ff ff       mov    -0x94c(%rbp),%edi
   201b93:       48 8d b5 d0 f6 ff ff    lea    -0x930(%rbp),%rsi

clang 13 hasn't bothered emitting the mov %eax, which is passing an 
uninitialized local to deliberately generate a memcheck error.


Looking at libc, I see for FreeBSD 13

   1372c4:       e8 87 89 f5 ff          call   8fc50 <__getosreldate>
   1372c9:       3d 9f 4f 12 00          cmp    $0x124f9f,%eax
   1372ce:       7c 10                   jl     1372e0 <_fstatfs+0x40> HERE1
   1372d0:       44 89 f7                mov    %r14d,%edi
   1372d3:       48 89 de                mov    %rbx,%rsi
   1372d6:       e8 85 d1 09 00          call   1d4460 <__sys_fstatfs@plt>
   1372db:       e9 22 01 00 00          jmp    137402 <_fstatfs+0x162> 
TO EXIT SEQUENCE

HERE1:

   1372e0:       48 8d 95 08 fe ff ff    lea    -0x1f8(%rbp),%rdx
   1372e7:       bf 8d 01 00 00          mov    $0x18d,%edi
   1372ec:       44 89 f6                mov    %r14d,%esi
   1372ef:       31 c0                   xor    %eax,%eax
   1372f1:       e8 8a c5 09 00          call   1d3880 <syscall@plt>
   1372f6:       85 c0                   test   %eax,%eax
   1372f8:       0f 85 04 01 00 00       jne    137402 <_fstatfs+0x162>

and 13.1

2b4:       e8 a7 c1 f5 ff          call   90460 <__getosreldate>
   1342b9:       3d 9f 4f 12 00          cmp    $0x124f9f,%eax
   1342be:       7c 25                   jl     1342e5 <_fstatfs+0x55> HERE1
   1342c0:       49 8b 07                mov    (%r15),%rax
   1342c3:       48 3b 45 e0             cmp    -0x20(%rbp),%rax
   1342c7:       0f 85 51 01 00 00       jne    13441e <_fstatfs+0x18e>
   1342cd:       44 89 f7                mov    %r14d,%edi
   1342d0:       48 89 de                mov    %rbx,%rsi
   1342d3:       48 81 c4 e8 01 00 00    add    $0x1e8,%rsp
   1342da:       5b                      pop    %rbx
   1342db:       41 5e                   pop    %r14
   1342dd:       41 5f                   pop    %r15
   1342df:       5d                      pop    %rbp

BINGO! TAIL CALL OPTIMIZATION

   1342e0:       e9 bb a0 09 00          jmp    1ce3a0 <__sys_fstatfs@plt>

HERE1

   1342e5:       48 8d 95 08 fe ff ff    lea    -0x1f8(%rbp),%rdx
   1342ec:       bf 8d 01 00 00          mov    $0x18d,%edi
   1342f1:       44 89 f6                mov    %r14d,%esi
   1342f4:       31 c0                   xor    %eax,%eax
   1342f6:       e8 d5 94 09 00          call   1cd7d0 <syscall@plt>
   1342fb:       85 c0                   test   %eax,%eax
   1342fd:       0f 85 04 01 00 00       jne    134407 <_fstatfs+0x177>

I don't think that there is much that I can do about that in Valgrind. 
The stat family callstacks will be a little less clear, but still usable.

And equally I don't suppose there's any chance that libc will get 
changed just for Valgrind.


A+

Paul