This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Simon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]