From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id A51783858D32 for ; Mon, 13 Mar 2023 16:13:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A51783858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x42e.google.com with SMTP id n16so1811862pfa.12 for ; Mon, 13 Mar 2023 09:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678724037; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HNXsz9OVqtSGHSB10srVIZ3fxjamfsti7e4+WElGN08=; b=aBZOa8xXa7J8KbCYEl0AdnI8qWsN3zqoBiJj7ct92O+/Nf0FYQnmQyQAoIofA1icwx zN1d7sCGfZOy7yPCUxWwWQwAwPoCSSSgolQ+ocrHLQ+kxJtCS9PEHt57ZEr/sKoxNmBO g9YDp+UjyBClJopqnNOeagZlGPX153U57YM/xnxkHbnwsvnEA/lV2e/MNmeJsJODBmKf stSNwLRUhGCzGj6HjzPGtkpi8FOBWUO16a4JArH0L0fQtHTHqKrXaQQJ+Gm3KR1/pjV2 xff1LJ28WJVPoghoCi93KoGPUrDZNkx7TAe/eW4iE0bQkPSAP0IQQ60WkPIwkoG4H4BQ Gg/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678724037; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HNXsz9OVqtSGHSB10srVIZ3fxjamfsti7e4+WElGN08=; b=iRO9ySuDmlxAuBHhPt8rkkEDBrZSfNSfFeL1Mfb+iQDdLbzwcCBAnK1n69JLvl+u37 rSzW4dJFuixYjDC72U9yFaraugXtOl64qgI+ZVPeKMvyB3BHV/J+hWWTQNu9ejFRQ7u+ 5c7LG4ZfmEWz5+kqZbQvfpFRUJ7GXSBLlUdTUrpQt/4Rr3fULRu5OyOyzPGkF8z28Liv kUlJGSBFB9WIOilB65r5Htnpn3PBj8wIbYalZJNau0q5QMcy7hqtbWv4d3/6BbivlL5t mwu2/Fi8SlZbpWn2AJtSK+8xID1VjuPY175ktWZ3Nybw0vKlga5XMNoJSPMyPn79+Gd9 q3kw== X-Gm-Message-State: AO0yUKXvqzGjrhj99OdlfvUp6eVKCALgGpwn55z68bFL2mpcQO764cEd vn8OcFnQeLoEKEp/hZkdxc4KxK0XKOd4xGgJAMWzmtoITwc= X-Google-Smtp-Source: AK7set+iH58xNyccXcyHUdP9DJbWnt8TEEy7skAygkr9xB7vBeB4xBBgnsXM5pqkPSxPBM/uYHpR/BvBQdb+UqY7qqk= X-Received: by 2002:a62:1746:0:b0:624:c7cc:3d0e with SMTP id 67-20020a621746000000b00624c7cc3d0emr1105892pfx.6.1678724037354; Mon, 13 Mar 2023 09:13:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergey Bugaev Date: Mon, 13 Mar 2023 19:13:46 +0300 Message-ID: Subject: Re: GCC miscompilation with __seg_fs To: Jakub Jelinek Cc: libc-alpha@sourceware.org, Florian Weimer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Mar 13, 2023 at 6:45=E2=80=AFPM Jakub Jelinek wr= ote: > You could also hide the fact that it is based on 0 pointer from the > compiler... But how would you do that? If we want the generated assembly to say %fs:0, the compiler needs to statically const-propagate the pointer to zero. If that's not important, this seems to do the trick: static inline size_t zero (void) { size_t res; asm ("xor %0, %0" : "=3Dr" (res)); return res; } #define THREAD_SELF_HIDDEN \ (*(tcbhead_t * __seg_fs *) zero ()) void assign_through_self_hidden (void) { THREAD_SELF_HIDDEN->some_member =3D 42; } // assign_through_self_hidden: // xor %rax, %rax // movq %fs:(%rax), %rax // movl $42, 8(%rax) // ret FWIW, without __seg_fs (where dereferencing a zero ptr is actual UB), assigning through *(int *) 0 is enough for GCC to consider the rest of the code dead, whereas an assignment through **(int **) 0 does not trigger that, but the store is still eliminated: void some_external_call (void); void deref_nullptr (void) { *(int *) 0 =3D 42; some_external_call (); } // deref_nullptr: // movl $0, 0 // ud2 void indirect_deref_nullptr (void) { **(int **) 0 =3D 42; some_external_call (); } // indirect_deref_nullptr: // jmp some_external_call > Feel free to file a bug report in GCC bugzilla, but that won't improve > anything on the already released compilers. I don't even have a GCC bugzilla account, so please file it yourself. But yes, this needs to be worked around in glibc in any case. Sergey