(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

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).

(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.

*** Bug 29850 has been marked as a duplicate of this bug. ***

(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.

Proposal to add kfails: https://sourceware.org/pipermail/gdb-patches/2022-December/194537.html

Sorry, I've been using "pointer guarding" here, but I meant to say "pointer mangling" ( https://sourceware.org/glibc/wiki/PointerEncryption ).

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>

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>