* [Bug 1889411] [NEW] RISC-V: Unable to unwind the stack upon signals
@ 2020-07-29 12:42 Bernhard Urban-Forster
2020-08-13 22:33 ` [Bug 1889411] " Alistair Francis
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Bernhard Urban-Forster @ 2020-07-29 12:42 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
Consider the following program:
===============================================================
#include <stdio.h>
#include <stdlib.h>
#define NOINLINE __attribute__ ((noinline))
void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ }
void NOINLINE level1(void) { abort_me(); }
void NOINLINE level2(void) { level1(); }
void NOINLINE level3(void) { level2(); }
void NOINLINE level4(void) { level3();}
int main(void) {
level4();
return 0;
}
===============================================================
$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c
$ qemu-riscv64 -g 31337 ./c &
$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c
Reading symbols from c...
Remote debugging using localhost:31337
Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
Breakpoint 1 at 0x4000000632: file c.c, line 7.
Continuing.
Breakpoint 1, abort_me () at c.c:7
7 abort(); /* trigger SIGABRT */
#0 abort_me () at c.c:7
#1 0x0000004000000642 in level1 () at c.c:11
#2 0x0000004000000658 in level2 () at c.c:15
#3 0x000000400000066e in level3 () at c.c:19
#4 0x0000004000000684 in level4 () at c.c:23
#5 0x000000400000069a in main () at c.c:27
===============================================================
So far so good, I get a proper backtrace as expected. If I let the
signal trigger however, gdb is not able to unwind the stack:
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
0x0000004000858074 in ?? ()
(gdb) bt
#0 0x0000004000858074 in ?? ()
I get the same behaviour for SIGSEGV and SIGILL, I didn't try other
signals. Apparently this scenario works on real hardware (see linked gdb
issue below), and presumably it would work with system qemu (I haven't
tested that yet though). So my guess is that qemu does something
differently around signal handling than the linux kernel.
Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b
RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1889411
Title:
RISC-V: Unable to unwind the stack upon signals
Status in QEMU:
New
Bug description:
Consider the following program:
===============================================================
#include <stdio.h>
#include <stdlib.h>
#define NOINLINE __attribute__ ((noinline))
void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ }
void NOINLINE level1(void) { abort_me(); }
void NOINLINE level2(void) { level1(); }
void NOINLINE level3(void) { level2(); }
void NOINLINE level4(void) { level3();}
int main(void) {
level4();
return 0;
}
===============================================================
$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c
$ qemu-riscv64 -g 31337 ./c &
$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c
Reading symbols from c...
Remote debugging using localhost:31337
Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
Breakpoint 1 at 0x4000000632: file c.c, line 7.
Continuing.
Breakpoint 1, abort_me () at c.c:7
7 abort(); /* trigger SIGABRT */
#0 abort_me () at c.c:7
#1 0x0000004000000642 in level1 () at c.c:11
#2 0x0000004000000658 in level2 () at c.c:15
#3 0x000000400000066e in level3 () at c.c:19
#4 0x0000004000000684 in level4 () at c.c:23
#5 0x000000400000069a in main () at c.c:27
===============================================================
So far so good, I get a proper backtrace as expected. If I let the
signal trigger however, gdb is not able to unwind the stack:
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
0x0000004000858074 in ?? ()
(gdb) bt
#0 0x0000004000858074 in ?? ()
I get the same behaviour for SIGSEGV and SIGILL, I didn't try other
signals. Apparently this scenario works on real hardware (see linked
gdb issue below), and presumably it would work with system qemu (I
haven't tested that yet though). So my guess is that qemu does
something differently around signal handling than the linux kernel.
Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b
RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1889411/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 1889411] Re: RISC-V: Unable to unwind the stack upon signals
2020-07-29 12:42 [Bug 1889411] [NEW] RISC-V: Unable to unwind the stack upon signals Bernhard Urban-Forster
@ 2020-08-13 22:33 ` Alistair Francis
2020-08-20 14:53 ` Thomas Huth
2020-10-20 4:17 ` Launchpad Bug Tracker
2 siblings, 0 replies; 4+ messages in thread
From: Alistair Francis @ 2020-08-13 22:33 UTC (permalink / raw)
To: qemu-devel
Can you test with mainline GDB and not a fork?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1889411
Title:
RISC-V: Unable to unwind the stack upon signals
Status in QEMU:
New
Bug description:
Consider the following program:
===============================================================
#include <stdio.h>
#include <stdlib.h>
#define NOINLINE __attribute__ ((noinline))
void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ }
void NOINLINE level1(void) { abort_me(); }
void NOINLINE level2(void) { level1(); }
void NOINLINE level3(void) { level2(); }
void NOINLINE level4(void) { level3();}
int main(void) {
level4();
return 0;
}
===============================================================
$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c
$ qemu-riscv64 -g 31337 ./c &
$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c
Reading symbols from c...
Remote debugging using localhost:31337
Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
Breakpoint 1 at 0x4000000632: file c.c, line 7.
Continuing.
Breakpoint 1, abort_me () at c.c:7
7 abort(); /* trigger SIGABRT */
#0 abort_me () at c.c:7
#1 0x0000004000000642 in level1 () at c.c:11
#2 0x0000004000000658 in level2 () at c.c:15
#3 0x000000400000066e in level3 () at c.c:19
#4 0x0000004000000684 in level4 () at c.c:23
#5 0x000000400000069a in main () at c.c:27
===============================================================
So far so good, I get a proper backtrace as expected. If I let the
signal trigger however, gdb is not able to unwind the stack:
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
0x0000004000858074 in ?? ()
(gdb) bt
#0 0x0000004000858074 in ?? ()
I get the same behaviour for SIGSEGV and SIGILL, I didn't try other
signals. Apparently this scenario works on real hardware (see linked
gdb issue below), and presumably it would work with system qemu (I
haven't tested that yet though). So my guess is that qemu does
something differently around signal handling than the linux kernel.
Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b
RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1889411/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 1889411] Re: RISC-V: Unable to unwind the stack upon signals
2020-07-29 12:42 [Bug 1889411] [NEW] RISC-V: Unable to unwind the stack upon signals Bernhard Urban-Forster
2020-08-13 22:33 ` [Bug 1889411] " Alistair Francis
@ 2020-08-20 14:53 ` Thomas Huth
2020-10-20 4:17 ` Launchpad Bug Tracker
2 siblings, 0 replies; 4+ messages in thread
From: Thomas Huth @ 2020-08-20 14:53 UTC (permalink / raw)
To: qemu-devel
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1889411
Title:
RISC-V: Unable to unwind the stack upon signals
Status in QEMU:
Incomplete
Bug description:
Consider the following program:
===============================================================
#include <stdio.h>
#include <stdlib.h>
#define NOINLINE __attribute__ ((noinline))
void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ }
void NOINLINE level1(void) { abort_me(); }
void NOINLINE level2(void) { level1(); }
void NOINLINE level3(void) { level2(); }
void NOINLINE level4(void) { level3();}
int main(void) {
level4();
return 0;
}
===============================================================
$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c
$ qemu-riscv64 -g 31337 ./c &
$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c
Reading symbols from c...
Remote debugging using localhost:31337
Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
Breakpoint 1 at 0x4000000632: file c.c, line 7.
Continuing.
Breakpoint 1, abort_me () at c.c:7
7 abort(); /* trigger SIGABRT */
#0 abort_me () at c.c:7
#1 0x0000004000000642 in level1 () at c.c:11
#2 0x0000004000000658 in level2 () at c.c:15
#3 0x000000400000066e in level3 () at c.c:19
#4 0x0000004000000684 in level4 () at c.c:23
#5 0x000000400000069a in main () at c.c:27
===============================================================
So far so good, I get a proper backtrace as expected. If I let the
signal trigger however, gdb is not able to unwind the stack:
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
0x0000004000858074 in ?? ()
(gdb) bt
#0 0x0000004000858074 in ?? ()
I get the same behaviour for SIGSEGV and SIGILL, I didn't try other
signals. Apparently this scenario works on real hardware (see linked
gdb issue below), and presumably it would work with system qemu (I
haven't tested that yet though). So my guess is that qemu does
something differently around signal handling than the linux kernel.
Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b
RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1889411/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug 1889411] Re: RISC-V: Unable to unwind the stack upon signals
2020-07-29 12:42 [Bug 1889411] [NEW] RISC-V: Unable to unwind the stack upon signals Bernhard Urban-Forster
2020-08-13 22:33 ` [Bug 1889411] " Alistair Francis
2020-08-20 14:53 ` Thomas Huth
@ 2020-10-20 4:17 ` Launchpad Bug Tracker
2 siblings, 0 replies; 4+ messages in thread
From: Launchpad Bug Tracker @ 2020-10-20 4:17 UTC (permalink / raw)
To: qemu-devel
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1889411
Title:
RISC-V: Unable to unwind the stack upon signals
Status in QEMU:
Expired
Bug description:
Consider the following program:
===============================================================
#include <stdio.h>
#include <stdlib.h>
#define NOINLINE __attribute__ ((noinline))
void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ }
void NOINLINE level1(void) { abort_me(); }
void NOINLINE level2(void) { level1(); }
void NOINLINE level3(void) { level2(); }
void NOINLINE level4(void) { level3();}
int main(void) {
level4();
return 0;
}
===============================================================
$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c
$ qemu-riscv64 -g 31337 ./c &
$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c
Reading symbols from c...
Remote debugging using localhost:31337
Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
Breakpoint 1 at 0x4000000632: file c.c, line 7.
Continuing.
Breakpoint 1, abort_me () at c.c:7
7 abort(); /* trigger SIGABRT */
#0 abort_me () at c.c:7
#1 0x0000004000000642 in level1 () at c.c:11
#2 0x0000004000000658 in level2 () at c.c:15
#3 0x000000400000066e in level3 () at c.c:19
#4 0x0000004000000684 in level4 () at c.c:23
#5 0x000000400000069a in main () at c.c:27
===============================================================
So far so good, I get a proper backtrace as expected. If I let the
signal trigger however, gdb is not able to unwind the stack:
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
0x0000004000858074 in ?? ()
(gdb) bt
#0 0x0000004000858074 in ?? ()
I get the same behaviour for SIGSEGV and SIGILL, I didn't try other
signals. Apparently this scenario works on real hardware (see linked
gdb issue below), and presumably it would work with system qemu (I
haven't tested that yet though). So my guess is that qemu does
something differently around signal handling than the linux kernel.
Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b
RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1889411/+subscriptions
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-10-20 4:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-29 12:42 [Bug 1889411] [NEW] RISC-V: Unable to unwind the stack upon signals Bernhard Urban-Forster
2020-08-13 22:33 ` [Bug 1889411] " Alistair Francis
2020-08-20 14:53 ` Thomas Huth
2020-10-20 4:17 ` Launchpad Bug Tracker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).