| Message ID | 20200306165000.3073-1-ssbssa@yahoo.de |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 46248 invoked by alias); 6 Mar 2020 16:50:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 46235 invoked by uid 89); 6 Mar 2020 16:50:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=inferior_ptid, HContent-Transfer-Encoding:8bit X-HELO: sonic304-22.consmr.mail.ir2.yahoo.com Received: from sonic304-22.consmr.mail.ir2.yahoo.com (HELO sonic304-22.consmr.mail.ir2.yahoo.com) (77.238.179.147) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Mar 2020 16:50:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1583513428; bh=tW6cymS3h0FLdNlJQQMqI5hHX5sxvLYZ53gya4pfZro=; h=From:To:Subject:Date:References:From:Subject; b=QvnD8vdiHOG8o9JD/+5jQ/T32WIPL44ZKkFSNOvChK3OaWUVfwuifR+4nDWwtmYmlBzDwflBNFdX+niBdJgKiraJ54jasj5dW1a4REmncP7qFrvc9FG6+qjoIHd7aqRLKyrJuA2ClMUGQQWEpFtATzh2JF5qxMfDmJXGtpCrDCXAItXKdGBi40HMrjbPVBGRrxqLSPQsc5aIqO1dIvE0XUw7eifuRoRD6ZWzZHefdzxP7oR+MVDtQrTNXFweuVloLvPKPTVUnvpLPL19sJbSgIIfHRP0ZVWNzdKm4o2MafoV5ByWa6AmdMe5WR1rg3zXs0COkHf0m8R5z6FjoVEiLg== Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ir2.yahoo.com with HTTP; Fri, 6 Mar 2020 16:50:28 +0000 Received: by smtp404.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d05c46fdda0a87725c4233f137369917; Fri, 06 Mar 2020 16:50:23 +0000 (UTC) From: "Hannes Domani via gdb-patches" <gdb-patches@sourceware.org> Reply-To: Hannes Domani <ssbssa@yahoo.de> To: gdb-patches@sourceware.org Subject: [PATCH] Don't try to get the TIB address without an inferior Date: Fri, 6 Mar 2020 17:50:00 +0100 Message-Id: <20200306165000.3073-1-ssbssa@yahoo.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit References: <20200306165000.3073-1-ssbssa.ref@yahoo.de> Content-Length: 1119 X-IsSubscribed: yes |
Commit Message
Terekhov, Mikhail 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
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
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
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 }
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
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?
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
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 --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);