gdb starts kdl: PANIC: spurious debug exception in kernel mode

[lucian]

Running on haiku-nightly-hrev36330-x86gcc4-raw.zip in Qemu.

I've created a small program:

int main()
{
  printf("a");
  return 0;
}

And ran:

$ gcc -g a.c
$ gdb ./a.out
(gdb) start
(gdb) n

After hitting n I immediately went to KDL. The bug happens on more complex programs too and even on prebuilt programs: gdb `which StyleEdit`. 100% reproducibility.

In KDL continue will lead to a subsequent panic, ad nauseam.

The panic title: PANIC: spurious debug exception in kernel mode (no condition recognized). I'll attach a syslog as soon as I learn how to get one out from qemu.

[Disreali]

i also experienced a couple instances of closing the gdb term would cause a kdl on hrev36330.

One was when Jukebox crashed. I select debug button, copied bt output and as some as I closed the gdb term, the system kdl-ed. I don't know it will help, but including the jukebox gdb

[lucian]

The hrev36340 commit fixes the unwanted trips to KDL. I'm not sure if this is another issue, or something related: stepping with n in gdb does not work, replying "cannot determine bounds of current function". continue however works.

[lucian]

Disreali, can you check with the latest nightly image if your problem is solved too (to be sure they are the same issue, and not distinct)?

[bonefish]

Replying to lucian:

The hrev36340 commit fixes the unwanted trips to KDL. I'm not sure if this is another issue, or something related: stepping with n in gdb does not work, replying "cannot determine bounds of current function". continue however works.

I've noticed that, too. gdb seems to have trouble with the syscall trampoline code. It is possible that special handling is needed for it, but not implemented. As long as debug info for the executed code is available it should work OK, though.