diff mbox

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

Message ID 20200306165000.3073-1-ssbssa@yahoo.de
State New
Headers show

Commit Message

Doug Evans via gdb-patches March 6, 2020, 4:50 p.m. UTC
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'

Now it will skip this part, there is no need to rebase the executable without
an inferior anyways.

gdb/ChangeLog:

2020-03-06  Hannes Domani  <ssbssa@yahoo.de>

	* windows-tdep.c (windows_solib_create_inferior_hook):
	Check inferior_ptid.
---
 gdb/windows-tdep.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Simon Marchi March 6, 2020, 4:57 p.m. UTC | #1
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'
> 
> Now it will skip this part, there is no need to rebase the executable without
> an inferior anyways.
> 
> gdb/ChangeLog:
> 
> 2020-03-06  Hannes Domani  <ssbssa@yahoo.de>
> 
> 	* windows-tdep.c (windows_solib_create_inferior_hook):
> 	Check inferior_ptid.
> ---
>  gdb/windows-tdep.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
> index 4e5d8303ca..a3bacc2211 100644
> --- a/gdb/windows-tdep.c
> +++ b/gdb/windows-tdep.c
> @@ -843,7 +843,8 @@ windows_solib_create_inferior_hook (int from_tty)
>      }
>    CORE_ADDR tlb;
>    gdb_byte buf[8];
> -  if (target_get_tib_address (inferior_ptid, &tlb)
> +  if (inferior_ptid != null_ptid
> +      && target_get_tib_address (inferior_ptid, &tlb)
>        && !target_read_memory (tlb + peb_offset, buf, ptr_bytes))
>      {
>        CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order);

It won't really make much of a difference in practice, but I think it would be
appropriate to use "target_has_memory" for this condition.

Simon
Simon Marchi March 6, 2020, 5:05 p.m. UTC | #2
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.

Simon
Doug Evans via gdb-patches March 6, 2020, 5:06 p.m. UTC | #3
Am Freitag, 6. März 2020, 17:57:30 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:

> 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'
> >
> > Now it will skip this part, there is no need to rebase the executable without
> > an inferior anyways.
> >
> > gdb/ChangeLog:
> >
> > 2020-03-06  Hannes Domani  <ssbssa@yahoo.de>
> >
> >     * windows-tdep.c (windows_solib_create_inferior_hook):
> >     Check inferior_ptid.
> > ---
> >  gdb/windows-tdep.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
> > index 4e5d8303ca..a3bacc2211 100644
> > --- a/gdb/windows-tdep.c
> > +++ b/gdb/windows-tdep.c
> > @@ -843,7 +843,8 @@ windows_solib_create_inferior_hook (int from_tty)
> >      }
> >    CORE_ADDR tlb;
> >    gdb_byte buf[8];
> > -  if (target_get_tib_address (inferior_ptid, &tlb)
> > +  if (inferior_ptid != null_ptid
> > +      && target_get_tib_address (inferior_ptid, &tlb)
> >        && !target_read_memory (tlb + peb_offset, buf, ptr_bytes))
> >      {
> >        CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order);
>
>
> It won't really make much of a difference in practice, but I think it would be
> appropriate to use "target_has_memory" for this condition.

I just tried it, but exec_target::has_memory() returns true, although no
program is running:

(gdb) l
1153    bool
1154    exec_target::has_memory ()
1155    {
1156      /* We can provide memory if we have any file/target sections to read
1157         from.  */
1158      return (current_target_sections->sections
1159              != current_target_sections->sections_end);
1160    }
1161
1162    char *
(gdb) p current_program_space->target_sections
$4 = {
  sections = 0x11f70630,
  sections_end = 0x11f70710
}
Doug Evans via gdb-patches March 6, 2020, 5:12 p.m. UTC | #4
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
Simon Marchi March 6, 2020, 5:13 p.m. UTC | #5
On 2020-03-06 12:06 p.m., Hannes Domani via gdb-patches wrote:
>  Am Freitag, 6. März 2020, 17:57:30 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> 
>> 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'
>>>
>>> Now it will skip this part, there is no need to rebase the executable without
>>> an inferior anyways.
>>>
>>> gdb/ChangeLog:
>>>
>>> 2020-03-06  Hannes Domani  <ssbssa@yahoo.de>
>>>
>>>      * windows-tdep.c (windows_solib_create_inferior_hook):
>>>      Check inferior_ptid.
>>> ---
>>>   gdb/windows-tdep.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
>>> index 4e5d8303ca..a3bacc2211 100644
>>> --- a/gdb/windows-tdep.c
>>> +++ b/gdb/windows-tdep.c
>>> @@ -843,7 +843,8 @@ windows_solib_create_inferior_hook (int from_tty)
>>>       }
>>>     CORE_ADDR tlb;
>>>     gdb_byte buf[8];
>>> -  if (target_get_tib_address (inferior_ptid, &tlb)
>>> +  if (inferior_ptid != null_ptid
>>> +      && target_get_tib_address (inferior_ptid, &tlb)
>>>         && !target_read_memory (tlb + peb_offset, buf, ptr_bytes))
>>>       {
>>>         CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order);
>>
>>
>> It won't really make much of a difference in practice, but I think it would be
>> appropriate to use "target_has_memory" for this condition.
> 
> I just tried it, but exec_target::has_memory() returns true, although no
> program is running:
> 
> (gdb) l
> 1153    bool
> 1154    exec_target::has_memory ()
> 1155    {
> 1156      /* We can provide memory if we have any file/target sections to read
> 1157         from.  */
> 1158      return (current_target_sections->sections
> 1159              != current_target_sections->sections_end);
> 1160    }
> 1161
> 1162    char *
> (gdb) p current_program_space->target_sections
> $4 = {
>   sections = 0x11f70630,
>   sections_end = 0x11f70710
> }
> 

Oh, right, perhaps target_has_execution then?
Simon Marchi March 6, 2020, 5:21 p.m. UTC | #6
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
Doug Evans via gdb-patches March 6, 2020, 5:41 p.m. UTC | #7
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
diff mbox

Patch

diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
index 4e5d8303ca..a3bacc2211 100644
--- a/gdb/windows-tdep.c
+++ b/gdb/windows-tdep.c
@@ -843,7 +843,8 @@  windows_solib_create_inferior_hook (int from_tty)
     }
   CORE_ADDR tlb;
   gdb_byte buf[8];
-  if (target_get_tib_address (inferior_ptid, &tlb)
+  if (inferior_ptid != null_ptid
+      && target_get_tib_address (inferior_ptid, &tlb)
       && !target_read_memory (tlb + peb_offset, buf, ptr_bytes))
     {
       CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order);