https://sourceware.org/bugzilla/show_bug.cgi?id=26316
Bug ID: 26316 Summary: [aarch64] gdb/regcache.c:182: internal-error: reg_buffer::reg_buffer(gdbarch*, bool): Assertion `gdbarch != NULL' failed. Product: gdb Version: 9.2 Status: NEW Severity: normal Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- Using gdb 9.2 on aarch64, and an exec using sve, I run into: ... $ gdb -batch a.out -ex r ../../gdb/regcache.c:182: internal-error: reg_buffer::reg_buffer(gdbarch*, bool): Assertion `gdbarch != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ... Backtrace: ... (gdb) bt #0 0x0000fffff7581828 in raise () from /lib64/libc.so.6 #1 0x0000fffff7582e4c in abort () from /lib64/libc.so.6 #2 0x0000aaaaab016cb4 in dump_core () at ../../gdb/utils.c:210 #3 0x0000aaaaab01bf88 in internal_vproblem ( problem=problem@entry=0xaaaaab63c728 <internal_error_problem>, file=file@entry=0xaaaaab27bf98 "../../gdb/regcache.c", line=line@entry=182, fmt=<optimized out>, ap=<error reading variable: Cannot access memory at address 0x0>) at ../../gdb/utils.c:420 #4 0x0000aaaaab01c114 in internal_verror ( file=file@entry=0xaaaaab27bf98 "../../gdb/regcache.c", line=line@entry=182, fmt=<optimized out>, ap=...) at ../../gdb/utils.c:445 #5 0x0000aaaaaadc14f0 in internal_error ( file=file@entry=0xaaaaab27bf98 "../../gdb/regcache.c", line=line@entry=182, fmt=<optimized out>) at ../../gdb/gdbsupport/errors.c:55 #6 0x0000aaaaaaeffdb4 in reg_buffer::reg_buffer (this=0xaaaaaba700c0, gdbarch=<optimized out>, has_pseudo=false) at ../../gdb/regcache.c:182 #7 0x0000aaaaaaf00538 in readable_regcache::readable_regcache (has_pseudo=false, gdbarch= 0x0, this=<optimized out>) at ../../gdb/regcache.h:267 #8 detached_regcache::detached_regcache (has_pseudo=false, gdbarch=0x0, this=<optimized out>) at ../../gdb/regcache.h:312 #9 regcache::regcache (aspace_=0xaaaaab9517c0, gdbarch=0x0, this=<optimized out>) at ../../gdb/regcache.c:202 #10 get_thread_arch_aspace_regcache (ptid=..., gdbarch=gdbarch@entry=0x0, aspace=0xaaaaab9517c0) at ../../gdb/regcache.c:330 #11 0x0000aaaaaaf00624 in get_thread_arch_regcache (ptid=..., gdbarch=0x0) at ../../gdb/regcache.c:343 #12 0x0000aaaaaaf006cc in get_thread_regcache (ptid=...) at ../../gdb/regcache.c:358 #13 0x0000aaaaaae2f430 in save_stop_reason (lp=lp@entry=0xaaaaaba252e0) at ../../gdb/linux-nat.c:2752 #14 0x0000aaaaaae305ec in linux_nat_filter_event (status=<optimized out>, lwpid=<optimized out>) at ../../gdb/linux-nat.c:3226 #15 linux_nat_wait_1 (target_options=9085, ourstatus=0xaaaa00000000, ptid=...) at ../../gdb/linux-nat.c:3385 #16 linux_nat_target::wait (this=<optimized out>, ptid=..., ourstatus=0xaaaa00000000, target_options=9085) at ../../gdb/linux-nat.c:3643 #17 0x0000aaaaaafd9640 in target_wait (ptid=<error reading variable: Cannot access memory at address 0x0>, status=status@entry=0xffffffffe6b8, options=options@entry=0) at ../../gdb/target.c:2059 #18 0x0000aaaaaae7a51c in startup_inferior (pid=pid@entry=9085, ntraps=ntraps@entry=1, last_waitstatus=last_waitstatus@entry=0x0, last_ptid=last_ptid@entry=0x0) at ../../gdb/nat/fork-inferior.c:485 #19 0x0000aaaaaada6218 in gdb_startup_inferior (pid=pid@entry=9085, num_traps=num_traps@entry=1) at ../../gdb/fork-child.c:131 #20 0x0000aaaaaadf797c in inf_ptrace_target::create_inferior (this=this@entry=0xaaaaab69e268 <the_aarch64_linux_nat_target>, exec_file=exec_file@entry=0xaaaaab9d7d90 "a.out", allargs="", env=env@entry=0xaaaaab8d8090, from_tty=from_tty@entry=0) at ../../gdb/inf-ptrace.c:143 #21 0x0000aaaaaae29ad8 in linux_nat_target::create_inferior (this=0xaaaaab69e268 <the_aarch64_linux_nat_target>, exec_file=0xaaaaab9d7d90 "a.out", allargs="", env=0xaaaaab8d8090, from_tty=0) at ../../gdb/linux-nat.c:1106 #22 0x0000aaaaaadfd564 in run_command_1 (args=<optimized out>, from_tty=0, run_how=RUN_NORMAL) at ../../gdb/infcmd.c:633 #23 0x0000aaaaaacf868c in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at ../../gdb/cli/cli-decode.c:1952 #24 0x0000aaaaaafe9934 in execute_command (p=<optimized out>, from_tty=0) at ../../gdb/top.c:651 #25 0x0000aaaaaae4b4d0 in catch_command_errors (command=command@entry=0x3d0904b5d26e0, arg=<optimized out>, from_tty=<optimized out>) at ../../gdb/main.c:400 #26 0x0000aaaaaae4d028 in captured_main_1 (context=<optimized out>) at ../../gdb/main.c:1213 #27 0x0000aaaaaae4d5f0 in captured_main (data=<optimized out>) at ../../gdb/main.c:1238 #28 gdb_main (args=<optimized out>) at ../../gdb/main.c:1263 #29 0x0000aaaaaac3b4f4 in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:40 ... -- You are receiving this mail because: You are on the CC list for the bug. |
https://sourceware.org/bugzilla/show_bug.cgi?id=26316
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> --- From debugging, I find that the problem is that aarch64_linux_nat_target::thread_architecture returns null. AFAIU, this should be fixed by: ... commit 6a5206eb2740e769bcb0500bdbc5998801d90ef6 Author: Luis Machado <[hidden email]> Date: Fri Jan 3 16:08:16 2020 -0300 [AArch64] Fix erroneous use of spu architecture bfd While investigating some SVE code, i noticed the use of two spu bfd variables. This looks like an oversight, as the "id" field is available for non-spu architectures as well, even though its primary use was the Cell BE architecture. gdb/ChangeLog: 2020-01-05 Luis Machado <[hidden email]> * aarch64-linux-nat.c (aarch64_linux_nat_target::thread_architecture): Use bfd_arch_aarch64 and bfd_mach_aarch64. ... -- You are receiving this mail because: You are on the CC list for the bug. |
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26316
Tom de Vries <vries at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |10.1 CC| |luis.machado at linaro dot org --- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to Tom de Vries from comment #1) > From debugging, I find that the problem is that > aarch64_linux_nat_target::thread_architecture returns null. AFAIU, this > should be fixed by: > ... > commit 6a5206eb2740e769bcb0500bdbc5998801d90ef6 > Author: Luis Machado <[hidden email]> > Date: Fri Jan 3 16:08:16 2020 -0300 > > [AArch64] Fix erroneous use of spu architecture bfd Confirmed :) -- You are receiving this mail because: You are on the CC list for the bug. |
Free forum by Nabble | Edit this page |