[Bug gdb/29449] New: Crash on load when there's no shared library support

["research_trasio at irq dot a4lg.com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29449

            Bug ID: 29449
           Summary: Crash on load when there's no shared library support
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: research_trasio at irq dot a4lg.com
  Target Milestone: ---

Commit: master (99c902690493e35aad16b2083bad34cf79c366bf)
Target (Reproduced):
-   x86_64-unknown-elf
-   riscv64-unknown-elf
Target (NOT Reproduced):
-   x86_64-unknown-linux-gnu
-   riscv64-linux-gnu

When a target file (possibly with symbols?) is loaded, GDB crashes.

Excerpts from GDB is as follows (I used `gdb --batch -x a.txt' to reproduce the
bug quickly but it's just a file command):

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000055555598fa44 in solib_create_inferior_hook (from_tty=0) at
/home/builduser/src/binutils-gdb/gdb/solib.c:1274
1274      ops->solib_create_inferior_hook (from_tty);
(gdb) bt
#0  0x000055555598fa44 in solib_create_inferior_hook (from_tty=0) at
/home/builduser/src/binutils-gdb/gdb/solib.c:1274
#1  0x00005555559be0a6 in symbol_file_command (args=<optimized out>,
from_tty=0) at /home/builduser/src/binutils-gdb/gdb/symfile.c:1655
#2  0x00005555557f3aa1 in file_command (arg=0x555556009d95
"targets/opensbi/fw_dynamic.elf", from_tty=0) at
/home/builduser/src/binutils-gdb/gdb/exec.c:555
#3  0x000055555570b7f5 in cmd_func (cmd=<optimized out>, args=<optimized out>,
from_tty=<optimized out>) at
/home/builduser/src/binutils-gdb/gdb/cli/cli-decode.c:2516
#4  0x0000555555a0f5c1 in execute_command (p=<optimized out>,
p@entry=0x555556009d90 "file targets/opensbi/fw_dynamic.elf", from_tty=0) at
/home/builduser/src/binutils-gdb/gdb/top.c:699
#5  0x00005555557f0215 in command_handler (command=0x555556009d90 "file
targets/opensbi/fw_dynamic.elf") at
/home/builduser/src/binutils-gdb/gdb/event-top.c:598
#6  0x0000555555a1075f in read_command_file
(stream=stream@entry=0x55555611ef90) at
/home/builduser/src/binutils-gdb/gdb/top.c:468
#7  0x000055555571a6f4 in script_from_file (stream=stream@entry=0x55555611ef90,
file=file@entry=0x7fffffffe532 "a.txt") at
/home/builduser/src/binutils-gdb/gdb/cli/cli-script.c:1625
#8  0x0000555555708193 in source_script_from_stream
(file_to_open=0x7fffffffdd30 "a.txt", file=0x7fffffffe532 "a.txt",
stream=0x55555611ef90) at
/home/builduser/src/binutils-gdb/gdb/cli/cli-cmds.c:715
#9  source_script_with_search (file=0x7fffffffe532 "a.txt", file@entry=<error
reading variable: value has been optimized out>, from_tty=<error reading
variable: value has been optimized out>, search_path=<error reading variable:
value has been optimized out>) at
/home/builduser/src/binutils-gdb/gdb/cli/cli-cmds.c:760
#10 0x0000555555883e23 in catch_command_errors (command=<optimized out>,
arg=<optimized out>, from_tty=<optimized out>, do_bp_actions=<optimized out>)
at /home/builduser/src/binutils-gdb/gdb/main.c:513
#11 0x0000555555883eb8 in execute_cmdargs
(cmdarg_vec=cmdarg_vec@entry=0x7fffffffdeb0,
file_type=file_type@entry=CMDARG_FILE, cmd_type=cmd_type@entry=CMDARG_COMMAND,
ret=ret@entry=0x7fffffffdea4) at
/home/builduser/src/binutils-gdb/gdb/main.c:605
#12 0x000055555588593d in captured_main_1 (context=<optimized out>) at
/home/builduser/src/binutils-gdb/gdb/main.c:1298
#13 0x000055555588650f in captured_main (data=0x7fffffffe0c0) at
/home/builduser/src/binutils-gdb/gdb/main.c:1319
#14 gdb_main (args=args@entry=0x7fffffffe0f0) at
/home/builduser/src/binutils-gdb/gdb/main.c:1344
#15 0x0000555555635e00 in main (argc=<optimized out>, argv=<optimized out>) at
/home/builduser/src/binutils-gdb/gdb/gdb.c:32
(gdb)


I bisected and found that commit cb275538dbddfbb3c2c372a665ac48e6f617ea33 is
the cause of this bug.

I think this crash happens when there's no shared library support (where
default solib data must be used and no one calls the set_solib_ops function). 
The same commit with x86_64-unknown-linux-gnu and riscv64-linux-gnu targets
were fine.
For such cases, current_target_so_ops should be used but... this is not used
anywhere, causing NULL target_so_ops to be used.

The only reason I haven't submitted the patch to fix this bug is because I
haven't completed the copyright assignment for my GDB contribution.
I think I shared enough information to reproduce and fix this bug but tell me
if not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.