[Bug middle-end/113991] New: [14 Regression] LTO miscompilation of vsftpd on s390x

[Bug middle-end/113991] New: [14 Regression] LTO miscompilation of vsftpd on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991

            Bug ID: 113991
           Summary: [14 Regression] LTO miscompilation of vsftpd on s390x
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57459&action=edit
vsftpd.tar.xz

We are seeing a miscompilation of vsftpd on s390x with r14-8885
Unfortunately, I haven't been able to further reduce the TUs which need -flto,
to me it looks like a register allocation bug.
Attached is a tarball with all the needed *.i files and a script to compile
them and link.
If one has Fedora s390x libraries -
libssl.so.3 libpam.so.0 libcap.so.2 libcrypto.so.3 libc.so.6 libaudit.so.1
libeconf.so.0 libm.so.6 libz.so.1 ld64.so.1 libcap-ng.so.0
are needed, then the reproducer is as root
gdb --args ./vsftpd -oanon_root=. -oallow_anon_ssl=true -obackground=false
run
and in another terminal
curl ftp://localhost/
It crashes with
#0  hash_pid (buckets=256, p_key=0x0) at standalone.c:338
#1  0x000002aa00010622 in hash_get_bucket (p_hash=p_hash@entry=0x2aa00031e10,
p_key=0x0) at hash.c:123
#2  hash_get_node_by_key (p_hash=p_hash@entry=0x2aa00031e10,
p_key=p_key@entry=0x0) at hash.c:134
#3  0x000002aa000106be in hash_lookup_entry (p_hash=0x2aa00031e10, p_key=0x0)
at hash.c:54
#4  hash_add_entry (p_hash=0x2aa00031e10, p_key=p_key@entry=0x0,
p_value=p_value@entry=0x2aa00032684) at hash.c:67
#5  0x000002aa00009ce0 in vsf_standalone_main () at standalone.c:202
#6  main (argc=<optimized out>, argv=<optimized out>) at main.c:158
Now, main which has vsf_standalone_main and tons of other stuff inlined into it
has
2 calls to hash_add_entry, one at standalone.c:202 and one at standalone.c:350
The one that crashes here is the one at line 202, in *.optimized dump it still
looks like
  [standalone.c:202:9] hash_add_entry (_344, [standalone.c:202:48] &new_child,
_384);
and so the second argument (%r3) is address of a local new_child variable.
That seems to be the case also before the register allocation, e.g. asmcons
has:
(insn 1527 1524 1528 153 (set (reg:DI 4 %r4)
        (reg/f:DI 185 [ _384 ])) "standalone.c":202:9 1477 {*movdi_64}
     (expr_list:REG_DEAD (reg/f:DI 185 [ _384 ])
        (nil)))
(insn 1528 1527 1529 153 (set (reg:DI 3 %r3)
        (reg/f:DI 777)) "standalone.c":202:9 1477 {*movdi_64}
     (expr_list:REG_EQUAL (plus:DI (reg/f:DI 34 %fp)
            (const_int -648 [0xfffffffffffffd78]))
        (nil)))
(insn 1529 1528 1530 153 (set (reg:DI 2 %r2)
        (mem/f/c:DI (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags
0x182])
                    (const_int 3096 [0xc18]))) [3 s_p_pid_ip_hash+0 S8 A64]))
"standalone.c":202:9 1477 {*movdi_64}
     (nil))
(call_insn 1530 1529 3721 153 (parallel [
            (call (mem:QI (symbol_ref:DI ("hash_add_entry") [flags 0x3] 
<function_decl 0x3ffb41ca900 hash_add_entry>) [0 hash_add_entry S1 A8])
                (const_int 0 [0]))
            (clobber (reg:DI 14 %r14))
        ]) "standalone.c":202:9 2198 {*brasl}
     (expr_list:REG_DEAD (reg:DI 4 %r4)
        (expr_list:REG_DEAD (reg:DI 3 %r3)
            (expr_list:REG_DEAD (reg:DI 2 %r2)
                (expr_list:REG_CALL_DECL (symbol_ref:DI ("hash_add_entry")
[flags 0x3]  <function_decl 0x3ffb41ca900 hash_add_entry>)
                    (nil)))))
    (expr_list:DI (use (reg:DI 2 %r2))
        (expr_list:DI (use (reg:DI 3 %r3))
            (expr_list:DI (use (reg:DI 4 %r4))
                (nil)))))
and pseudo 777 has a single initialization in
(insn 669 668 670 73 (parallel [
            (set (reg/f:DI 777)
                (plus:DI (reg/f:DI 34 %fp)
                    (const_int -648 [0xfffffffffffffd78])))
            (clobber (reg:CC 33 %cc))
        ]) "sysutil.c":700:16 1831 {*adddi3}
     (expr_list:REG_UNUSED (reg:CC 33 %cc)
        (nil)))     
But in the end after RA this becomes
(insn 1527 1524 1528 157 (set (reg:DI 4 %r4)
        (reg/f:DI 6 %r6 [orig:185 _384 ] [185])) "standalone.c":202:9 1477
{*movdi_64}
     (nil))
(insn 1528 1527 1529 157 (set (reg:DI 3 %r3)
        (reg/f:DI 7 %r7 [777])) "standalone.c":202:9 1477 {*movdi_64}
     (expr_list:REG_EQUAL (plus:DI (reg/f:DI 34 %fp)
            (const_int -648 [0xfffffffffffffd78]))
        (nil)))
(insn 1529 1528 1530 157 (set (reg:DI 2 %r2)
        (mem/f/c:DI (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags
0x182])
                    (const_int 3096 [0xc18]))) [3 s_p_pid_ip_hash+0 S8 A64]))
"standalone.c":202:9 1477 {*movdi_64}
     (nil))
(call_insn 1530 1529 3721 157 (parallel [
            (call (mem:QI (symbol_ref:DI ("hash_add_entry") [flags 0x3] 
<function_decl 0x3ffb41ca900 hash_add_entry>) [0 hash_add_entry S1 A8])
                (const_int 0 [0]))
            (clobber (reg:DI 14 %r14))
        ]) "standalone.c":202:9 2198 {*brasl}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("hash_add_entry") [flags 0x3] 
<function_decl 0x3ffb41ca900 hash_add_entry>)
        (nil))
    (expr_list:DI (use (reg:DI 2 %r2))
        (expr_list:DI (use (reg:DI 3 %r3))
            (expr_list:DI (use (reg:DI 4 %r4))
                (nil)))))
and the %r7 contains NULL in there, while it clearly should be never NULL
because it is an address of an automatic variable.

[Bug middle-end/113991] [14 Regression] LTO miscompilation of vsftpd on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
           Priority|P3                          |P1
                 CC|                            |krebbel at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If one doesn't have the needed libraries,
gcc -o vsftpd access.o ascii.o banner.o features.o filestr.o ftpcmdio.o
ftpdataio.o ftppolicy.o hash.o ipaddrparse.o logging.o ls.o main.o netstr.o
oneprocess.o opts.o parseconf.o postlogin.o postprivparent.o prelogin.o
privops.o privsock.o ptracesandbox.o readwrite.o secbuf.o seccompsandbox.o
secutil.o ssl.o sslslave.o standalone.o str.o strlist.o sysdeputil.o sysstr.o
sysutil.o tcpwrap.o tunables.o twoprocess.o utility.o -pie -fPIE
-Wl,--unresolved-symbols=ignore-all -fdump-tree-optimized
-fdump-rtl-final-details
seems to emit the final dump of the exactly same size, so I'd expect that it
has the same problem.

[Bug middle-end/113991] [14 Regression] LTO miscompilation of vsftpd on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Maybe it is a bug in the app (or kernel or glibc) though.
Under the debugger, I see the value of %r7 is still &new_child at before the
call at line 189:
189             new_child = vsf_sysutil_fork_isolate_failok();
190           }
191         }
192         else
193         {
194           new_child = vsf_sysutil_fork_failok();
195         }
196         if (new_child != 0)
197         {
198           /* Parent context */
199           vsf_sysutil_close(new_client_sock);
200           if (new_child > 0)
201           {
202             hash_add_entry(s_p_pid_ip_hash, (void*)&new_child, p_raw_addr);
That vsf_sysutil_fork_isolate_failok call calls the glibc clone function with
clone(NULL, NULL, CLONE_NEWPID | CLONE_NEWIPC | SIGCHLD, NULL)
arguments and the function doesn't directly use %r7 which I think is call-saved
register, but when the glibc clone returns in the parent, the %r7 register is
already 0.

[Bug middle-end/113991] [14 Regression] LTO miscompilation of vsftpd on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually it seems like a glibc bug to me, though what vsftpd is totally weird.
Seems glibc clone on all arches always errors when the first or second argument
is NULL and that is exactly what
vsf_sysutil_fork_isolate_failok and vsf_sysutil_fork_newnet do:
    int ret = clone(NULL, NULL, CLONE_NEWPID | CLONE_NEWIPC | SIGCHLD, NULL);
    int ret = clone(NULL, NULL, CLONE_NEWNET | SIGCHLD, NULL);
so I have no idea who added this stuff to vsftpd and why when it couldn't ever
work.
Or does it work say on musl?
Anyway, the glibc bug is that both s390x and s390 clone in that failure case
clobbers %r7:
        stmg    %r6,%r7,48(%r15)        /* Save registers.  */
        cfi_offset (%r7,-104)
        cfi_offset (%r6,-112)
        ltgr    %r7,%r2                 /* check fn and move to %r7 */
        jz      error                   /* no NULL function pointers */
        lghi    %r0,-16                 /* Align the child_stack to a ...  */
        ngr     %r3,%r0                 /* double word boundary and ...  */
        jz      error                   /* avoid NULL stack pointers.  */
...
error:
        lghi    %r2,-EINVAL
        jg      SYSCALL_ERROR_LABEL
Guess error: label should either lmg     %r6,%r7,48(%r15) or lg %r7,56(%r15)

[Bug middle-end/113991] [14 Regression] LTO miscompilation of vsftpd on s390x

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=31402