[PATCH] Don't try to get the TIB address without an inferior

Hannes Domani via gdb-patches gdb-patches@sourceware.org
Fri Mar 6 17:42:00 GMT 2020


 Am Freitag, 6. März 2020, 18:21:44 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:

> On 2020-03-06 12:12 p.m., Hannes Domani via gdb-patches wrote:
> >  Am Freitag, 6. März 2020, 18:05:50 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> >
> >> On 2020-03-06 11:57 a.m., Simon Marchi wrote:
> >>> On 2020-03-06 11:50 a.m., Hannes Domani via gdb-patches wrote:
> >>>> The target_get_tib_address call always fails in this case, and there is an
> >>>> error when changing the program with the file command:
> >>>>
> >>>> (gdb) file allocer64.exe
> >>>> Reading symbols from allocer64.exe...
> >>>> You can't do that when your target is `exec'
> >>
> >> Actually, can you precise the steps for reproducing this issue?  Just calling
> >> "file" doesn't cause windows_solib_create_inferior_hook to be called in my
> >> build*, so there must be something more to it.
> >>
> >> * My build is an --enable-targets=all on a Linux host, in which I load a binary
> >> compiled with x86_64-w64-mingw32-gcc.
> >
> > Just starting, then the file command is enough for me:
> >
> >> \gdb\build64\gdb-git\gdb\gdb.exe -q
> > (gdb) file allocer64.exe
> > Reading symbols from allocer64.exe...
> > You can't do that when your target is `exec'
> >
> >
> > Backtrace of my try with target_has_memory:
> >
> > (gdb) bt
> > #0  exec_target::has_memory (this=0x993630 <exec_ops>) at C:/src/repos/binutils-gdb.git/gdb/exec.c:1158
> > #1  0x000000000065a8c5 in target_has_memory_1 () at C:/src/repos/binutils-gdb.git/gdb/target.c:197
> > #2  0x00000000006c9c5c in windows_solib_create_inferior_hook (from_tty=<optimized out>) at C:/src/repos/binutils-gdb.git/gdb/windows-tdep.c:846
> > #3  0x0000000000640ee6 in symbol_file_command (args=args@entry=0x2fb565 "allocer64.exe", from_tty=from_tty@entry=1)
> >     at C:/src/repos/binutils-gdb.git/gdb/symfile.c:1663
> > #4  0x000000000051809e in file_command (arg=0x2fb565 "allocer64.exe", from_tty=1) at C:/src/repos/binutils-gdb.git/gdb/exec.c:536
> > #5  0x0000000000481022 in cmd_func (cmd=0x993630 <exec_ops>, args=0x1 <error: Cannot access memory at address 0x1>, from_tty=2)
> >     at C:/src/repos/binutils-gdb.git/gdb/cli/cli-decode.c:1952
> > #6  0x0000000000673388 in execute_command (p=<optimized out>, p@entry=0x2fb560 "", from_tty=1) at C:/src/repos/binutils-gdb.git/gdb/top.c:655
> > #7  0x0000000000515f34 in command_handler (command=0x2fb560 "") at C:/src/repos/binutils-gdb.git/gdb/event-top.c:587
> > #8  0x0000000000516de2 in command_line_handler (rl=...) at C:/src/repos/binutils-gdb.git/gdb/event-top.c:772
> > #9  0x0000000000516713 in gdb_rl_callback_handler (rl=0x11f3d9f0 "file allocer64.exe")
> >     at c:/msys64/mingw64/x86_64-w64-mingw32/include/c++/9.2.0/bits/unique_ptr.h:153
> > #10 0x00000000006e449c in rl_callback_read_char () at C:/src/repos/binutils-gdb.git/readline/readline/callback.c:281
> > #11 0x0000000000515a8e in gdb_rl_callback_read_char_wrapper_noexcept () at C:/src/repos/binutils-gdb.git/gdb/event-top.c:176
> > #12 0x00000000005165c4 in gdb_rl_callback_read_char_wrapper (client_data=<optimized out>) at C:/src/repos/binutils-gdb.git/gdb/event-top.c:192
> > #13 0x00000000005158d2 in stdin_event_handler (error=<optimized out>, client_data=0x2f5f10) at C:/src/repos/binutils-gdb.git/gdb/event-top.c:515
> > #14 0x00000000005148f0 in handle_file_event (ready_mask=2, file_ptr=0x3a9290) at C:/src/repos/binutils-gdb.git/gdb/event-loop.c:701
> > #15 gdb_wait_for_event (block=<optimized out>) at C:/src/repos/binutils-gdb.git/gdb/event-loop.c:852
> > #16 gdb_wait_for_event (block=<optimized out>) at C:/src/repos/binutils-gdb.git/gdb/event-loop.c:714
> > #17 0x0000000000514ace in gdb_do_one_event () at C:/src/repos/binutils-gdb.git/gdb/event-loop.c:313
> > #18 0x0000000000514bbe in gdb_do_one_event () at C:/src/repos/binutils-gdb.git/gdb/event-loop.c:337
> > #19 start_event_loop () at C:/src/repos/binutils-gdb.git/gdb/event-loop.c:337
> > #20 0x0000000000593b32 in captured_command_loop () at C:/src/repos/binutils-gdb.git/gdb/main.c:360
> > #21 0x0000000000595955 in captured_main (data=0x101bfdc0) at C:/src/repos/binutils-gdb.git/gdb/main.c:1198
> > #22 gdb_main (args=args@entry=0x101bfe20) at C:/src/repos/binutils-gdb.git/gdb/main.c:1213
> > #23 0x0000000000987617 in main (argc=3, argv=0xd4850) at C:/src/repos/binutils-gdb.git/gdb/gdb.c:32
> >
>
> Ah, and this is what I get:
>
> #0  svr4_solib_create_inferior_hook (from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/solib-svr4.c:3016
> #1  0x00000000016a9565 in solib_create_inferior_hook (from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/solib.c:1211
> #2  0x00000000017308fd in symbol_file_command (args=0x603000084c75 "/tmp/test.exe", from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symfile.c:1663
> #3  0x0000000000f2aef7 in file_command (arg=0x603000084c75 "/tmp/test.exe", from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/exec.c:536
>
> The gdbarch used in the solib_create_inferior_hook function is a Linux one, even though
> the loaded binary is a Windows PE executable.  I don't know much about that, but that looks
> fishy.  Anyway, that's a problem that should be investigated separately from your patch.
>
> So your patch LGTM, using either "inferior_ptid != null_ptid" or "target_has_execution"
> as the condition, as you see fit.

Pushed with target_has_execution, thanks.


Regards
Hannes Domani



More information about the Gdb-patches mailing list