From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id C1DE03959E79; Wed,  7 Dec 2022 10:31:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1DE03959E79
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1670409063;
	bh=W7UTvv1A6JUP6X/tWsXIqAklKp7ZFz/ni4v05oJUT7g=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=FUg27z+FBHOF6HQcqfH97Ec0BcziPEnpghavWGubYo2HZs3DqvEwq1iaubPhxRP17
	 SETN8r2/snKGaeFQMDcOiMyM9R8E+hWtJJZF9XQw2Ivs3WoCRXS9iq+3lu5XLuBEUD
	 fxmBR02FqWjCYMjyEbyhFbPLqbYZAgqu5U0hzOGw=
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over
 longjmp(1)
Date: Wed, 07 Dec 2022 10:31:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-26967-4717-l20devhzgc@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-26967-4717@http.sourceware.org/bugzilla/>
References: <bug-26967-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D26967

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #3)
> (In reply to Tom de Vries from comment #2)
>=20
> > Perhaps this once was set, but switched off due to problems.  There are
> > known issues with this for linux related to pointer guarding of the pc =
in
> > jmp_buf.
>=20
> My recollection is that this is why it isn't enabled.
> If we know a platform uses pointer guarding, we should
> disable this approach.  The probes approach doesn't have
> this problem IIRC.

Thanks for the info.

Ack, the probes approach doesn't have that problem.

I suppose the difficulty lies in determining whether a platform indeed does=
 use
pointer guarding.

Maybe a configure time test could be used, like so:
...
$ cat test.c
#include <stdio.h>
#include <setjmp.h>

jmp_buf env;

void * __attribute__((noinline))
current_pc (void)
{
  return __builtin_return_address (0);
}

int
main (void)
{
  void *pc1, *pc2;

  pc1 =3D current_pc ();
  int res =3D setjmp (env);
  pc2 =3D current_pc ();

  int found =3D 0;
  if (res =3D=3D 0)
    {
      int n =3D sizeof (env->__jmpbuf) / sizeof (env->__jmpbuf[0]);
      for (int i =3D 0; i < n; ++i)
        {
          void *entry =3D (void *) env->__jmpbuf[i];
          if (pc1 <=3D entry && entry <=3D pc2)
            {
              /* printf ("found pc in jmp_buf at index %d\n", i); */
              found =3D 1;
            }
        }
      longjmp (env, 1);
    }

  if (found)
    printf ("no pointer mangling\n");
  else
    printf ("pointer mangling\n");

  return 0;
}
...
but this one already doesn't compile on s390x due to a different jmp_buf
layout.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=