* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
@ 2021-01-08 14:28 ` vries at gcc dot gnu.org
2021-01-27 15:17 ` vries at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-01-08 14:28 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> (which makes you wonder whether a
> gdb command probes ignore could be useful).
Filed https://sourceware.org/bugzilla/show_bug.cgi?id=27159
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
2021-01-08 14:28 ` [Bug testsuite/26967] " vries at gcc dot gnu.org
@ 2021-01-27 15:17 ` vries at gcc dot gnu.org
2022-12-05 23:33 ` tromey at sourceware dot org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2021-01-27 15:17 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
While working on PR27205 I figured out what happens.
Without longjmp probes in libc, we try to fall back to using longjmp_names
breakpoints, but when these trigger we don't manage to recuperate the pc from
jmp_buf because tdep->jb_pc_offset is not set (in other words, -1).
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.
Anyway, we could detect this in the "set debug infrun 1" output:
...
[infrun] process_event_stop_test: BPSTAT_WHAT_SET_LONGJMP_RESUME
(!gdbarch_get_longjmp_target)
...
and then allow the behaviour reported in this PR.
However, AFAIU that still wouldn't work for -m32, because there
tdep->jb_pc_offset is defined and then we run into pointer guarding (see
PR27205 for what that looks like).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
2021-01-08 14:28 ` [Bug testsuite/26967] " vries at gcc dot gnu.org
2021-01-27 15:17 ` vries at gcc dot gnu.org
@ 2022-12-05 23:33 ` tromey at sourceware dot org
2022-12-07 8:33 ` vries at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: tromey at sourceware dot org @ 2022-12-05 23:33 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Tom de Vries from comment #2)
> 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.
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
` (2 preceding siblings ...)
2022-12-05 23:33 ` tromey at sourceware dot org
@ 2022-12-07 8:33 ` vries at gcc dot gnu.org
2022-12-07 10:31 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-07 8:33 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
*** Bug 29850 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
` (3 preceding siblings ...)
2022-12-07 8:33 ` vries at gcc dot gnu.org
@ 2022-12-07 10:31 ` vries at gcc dot gnu.org
2022-12-07 10:36 ` vries at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-07 10:31 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- 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)
>
> > 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.
>
> 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 = current_pc ();
int res = setjmp (env);
pc2 = current_pc ();
int found = 0;
if (res == 0)
{
int n = sizeof (env->__jmpbuf) / sizeof (env->__jmpbuf[0]);
for (int i = 0; i < n; ++i)
{
void *entry = (void *) env->__jmpbuf[i];
if (pc1 <= entry && entry <= pc2)
{
/* printf ("found pc in jmp_buf at index %d\n", i); */
found = 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
` (4 preceding siblings ...)
2022-12-07 10:31 ` vries at gcc dot gnu.org
@ 2022-12-07 10:36 ` vries at gcc dot gnu.org
2022-12-07 15:10 ` vries at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-07 10:36 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Proposal to add kfails:
https://sourceware.org/pipermail/gdb-patches/2022-December/194537.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
` (5 preceding siblings ...)
2022-12-07 10:36 ` vries at gcc dot gnu.org
@ 2022-12-07 15:10 ` vries at gcc dot gnu.org
2022-12-07 15:45 ` cvs-commit at gcc dot gnu.org
2024-03-20 18:24 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: vries at gcc dot gnu.org @ 2022-12-07 15:10 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Sorry, I've been using "pointer guarding" here, but I meant to say "pointer
mangling" ( https://sourceware.org/glibc/wiki/PointerEncryption ).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
` (6 preceding siblings ...)
2022-12-07 15:10 ` vries at gcc dot gnu.org
@ 2022-12-07 15:45 ` cvs-commit at gcc dot gnu.org
2024-03-20 18:24 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-12-07 15:45 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b5e7cd5cd3d1f90d0e7e58679a0782816bd5434f
commit b5e7cd5cd3d1f90d0e7e58679a0782816bd5434f
Author: Tom de Vries <tdevries@suse.de>
Date: Wed Dec 7 16:45:26 2022 +0100
[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp
Add KFAILs in test-case gdb.base/longjmp.exp for PR gdb/26967, covering
various ways that gdb is unable to recover the longjmp target if the libc
probe is not supported.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug testsuite/26967] FAIL: gdb.base/longjmp.exp: next over longjmp(1)
2020-11-28 12:44 [Bug testsuite/26967] New: FAIL: gdb.base/longjmp.exp: next over longjmp(1) vries at gcc dot gnu.org
` (7 preceding siblings ...)
2022-12-07 15:45 ` cvs-commit at gcc dot gnu.org
@ 2024-03-20 18:24 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-20 18:24 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26967
--- Comment #9 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d51a931152993fb095fd52083f2ba17d19e32ffd
commit d51a931152993fb095fd52083f2ba17d19e32ffd
Author: Tom de Vries <tdevries@suse.de>
Date: Wed Mar 20 19:23:48 2024 +0100
[gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases
On aarch64-linux (debian 12), when running test-case
gdb.base/longjmp-until-in-main.exp, I run into:
...
(gdb) until 33^M
warning: Breakpoint address adjusted from 0x70f727c678928489 to
0xfff727c678928489.^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0xfff727c678928489^M
^M
0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main
...
This is PR gdb/26967: no longjmp probe is available:
...
(gdb) info probes stap libc ^longjmp$^M
No probes matched.^M
...
and glibc applies pointer mangling which makes it fairly difficult for gdb
to
get the longjmp target.
There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit
b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp").
Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in
this and one more test-case.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread