From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 3E1A1385842A; Tue, 28 Feb 2023 12:41:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E1A1385842A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677588102;
	bh=uUQ1su0Xk/QxNSsm+nYP3mNIpNBKnLy+vqVR0kjjrTk=;
	h=From:To:Subject:Date:From;
	b=OEijBoJnX7PCP5LMVly0ykWNLsxJyXaX6H4C/yhRSGX/DDYZZLsyWEl5rV5TkCMBR
	 p0hdMpcTCewWICA6VfgCWk7b41AzwLNfsxB+N84OTP1/vckbVTLs0zxXWANhI2E/3K
	 LVXODCEwFJUI+GbUMpOmFkMGQXem8StdoyVmnzqs=
From: "andrew.cooper3 at citrix dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/108968] New: fanalyzer false positive with the
 uninitalised-ness of the stack pointer
Date: Tue, 28 Feb 2023 12:41:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: andrew.cooper3 at citrix dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-108968-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

            Bug ID: 108968
           Summary: fanalyzer false positive with the uninitalised-ness of
                    the stack pointer
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andrew.cooper3 at citrix dot com
  Target Milestone: ---

I experimented with -fanalyzer on Xen, given all the recent work on Linux.=
=20
We're quite similar, but one area where we are very different is accessing
per-cpu variables.

For architectural reasons (i.e. because we were virtualising Linux, and Lin=
ux
uses %gs for its per-cpu variables), Xen doesn't.  In Xen, we have a block =
of
metadata at the base of the stack, and the stack suitably aligned such that=
 we
can do something like this:

  static inline struct cpu_info *get_cpu_info(void)
  {
    register unsigned long sp asm("rsp");

    return (struct cpu_info *)((sp | (STACK_SIZE - 1)) + 1) - 1;
  }

Which turns into roughly:

  ptr =3D ((rsp | 0x7fff) + 1) - sizeof(struct cpu_info)

which is correct and work suitably due to the alignment of the stack in the
first place.

Unfortunately, it triggers:

  ./arch/x86/include/asm/current.h:95:5: error: use of uninitialized value =
'sp'
[CWE-457] [-Werror=3Danalyzer-use-of-uninitialized-value]

reliably, every time macros such as `current` get expanded, which is
everywhere.


The reality is that the stack pointer is never uninitialised.  It is
unpredictable in the general case, but implementations can account for and
remove that unpredictability.

The normal trick to hide a variable from uninitialised handling (e.g. to as=
m(""
: "+g"(var)); ) doesn't work, as it suffers from the same error.

Is there any way to tell fanalyzer that this value really isn't uninitialis=
ed?=20
I can't see anything obvious.


I can work around the warning by doing:

  unsigned long sp;
  asm ( "mov %%rsp, %0" : "=3Dr" (sp) );

but this impacts code generation quite substantially.  This primitive is us=
ed
all over the place, and the regular C form undergoes far better CSE than the
explicit mov to retrieve the stack pointer.=