[PATCH 0/7] Add "Windows" OS ABI

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/7] Add "Windows" OS ABI

Sourceware - gdb-patches mailing list
On 2020-04-01 5:42 p.m., Pedro Alves wrote:

> On 3/16/20 5:08 PM, Simon Marchi via Gdb-patches wrote:
>> This patchset started out as a single patch to have the OS ABI Cygwin
>> applied to Windows x86-64 binaries, here:
>>
>>     https://sourceware.org/legacy-ml/gdb-patches/2020-03/msg00195.html
>>
>> with the follow-up here:
>>
>>     https://sourceware.org/pipermail/gdb-patches/2020-March/000022.html
>>
>> Eli pointed out that it doesn't make sense for binaries compilied with
>> MinGW to have the Cygwin OS ABI, that there should be separate OS ABIs
>> for Cygwin and non-Cygwin Windows binaries.  This already came up in the
>> following bug report:
>>
>>     https://sourceware.org/bugzilla/show_bug.cgi?id=21500#add_comment
>
> Hurray.  Thanks for doing this.  Recently, another spot that could use
> this was added in windows-tdep.c.  See:
>
>   https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00048.html
>
> Look for "bummer".

Ok, I'll see what I can do.

Simon
Reply | Threaded
Open this post in threaded view
|

[PATCH] gdb: stop using host-dependent signal numbers in, windows-tdep.c (was: Re: [PATCH 0/7] Add "Windows" OS ABI)

Simon Marchi-4
On 2020-04-01 5:56 p.m., Simon Marchi via Gdb-patches wrote:

> On 2020-04-01 5:42 p.m., Pedro Alves wrote:
>> On 3/16/20 5:08 PM, Simon Marchi via Gdb-patches wrote:
>>> This patchset started out as a single patch to have the OS ABI Cygwin
>>> applied to Windows x86-64 binaries, here:
>>>
>>>     https://sourceware.org/legacy-ml/gdb-patches/2020-03/msg00195.html
>>>
>>> with the follow-up here:
>>>
>>>     https://sourceware.org/pipermail/gdb-patches/2020-March/000022.html
>>>
>>> Eli pointed out that it doesn't make sense for binaries compilied with
>>> MinGW to have the Cygwin OS ABI, that there should be separate OS ABIs
>>> for Cygwin and non-Cygwin Windows binaries.  This already came up in the
>>> following bug report:
>>>
>>>     https://sourceware.org/bugzilla/show_bug.cgi?id=21500#add_comment
>>
>> Hurray.  Thanks for doing this.  Recently, another spot that could use
>> this was added in windows-tdep.c.  See:
>>
>>   https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00048.html
>>
>> Look for "bummer".
>
> Ok, I'll see what I can do.
>
> Simon

Here's a patch that does that.  Note that I have only built-tested it.  I'm so
inefficient with Windows that if I wait until I have the time to actually try
it, I'll never get it done.  So I'm hoping that the Windows gurus can give it
a look.

Simon


From b08ef225a3fb1030e03ae53ed91fdc6f79550603 Mon Sep 17 00:00:00 2001
From: Simon Marchi <[hidden email]>
Date: Wed, 1 Apr 2020 22:01:54 -0400
Subject: [PATCH] gdb: stop using host-dependent signal numbers in
 windows-tdep.c

The signal enumeration in windows-tdep.c is defined differently whether
it is compiled on Cygwin or not.  This is problematic, since the code in
tdep files is not supposed to be influenced by the host platform (the
platform GDB itself runs on).

This makes a difference in windows_gdb_signal_to_target.  An obvious
example of clash is SIGABRT.  Let's pretend we are cross-debugging a
Cygwin process from a MinGW (non-Cygwin Windows) GDB.  If GDB needs to
translate the gdb signal number GDB_SIGNAL_ABRT into a target
equivalent, it would obtain the MinGW number (22), despite the target
being a Cygwin process.  Conversely, if debugging a MinGW process from a
Cygwin-hosted GDB, GDB_SIGNAL_ABRT would be converted to a Cygwin signal
number (6) despite the target being a MinGW process.  This is wrong,
since we want the result to depend on the target's platform, not GDB's
platform.

This known flaw was accepted because at the time we had a single OS ABI
(called Cygwin) for all Windows binaries (Cygwin ones and non-Cygwin
ones).  This limitation is now lifted, as we now have separate Windows
and Cygwin OS ABIs.  This means we are able to detect at runtime whether
the binary we are debugging is a Cygwin one or non-Cygwin one.

This patch splits the signal enum in two, one for the MinGW flavors and
one for Cygwin, removing all the ifdefs that made it depend on the host
platform.  It then makes two separate gdb_signal_to_target gdbarch
methods, that are used according to the OS ABI selected at runtime.

There is a bit of re-shuffling needed in how the gdbarch'es are
initialized, but nothing major.

gdb/ChangeLog:

        * windows-tdep.h (windows_init_abi): Add comment.
        (cygwin_init_abi): New declaration.
        * windows-tdep.c: Split signal enumeration in two, one for
        Windows and one for Cygwin.
        (windows_gdb_signal_to_target): Only deal with signal of the
        Windows OS ABI.
        (cygwin_gdb_signal_to_target): New function.
        (windows_init_abi): Rename to windows_init_abi_common, don't set
        gdb_signal_to_target gdbarch method.  Add new new function with
        this name.
        (cygwin_init_abi): New function.
        * amd64-windows-tdep.c (amd64_windows_init_abi_common): Add
        comment.  Don't call windows_init_abi.
        (amd64_windows_init_abi): Add comment, call windows_init_abi.
        (amd64_cygwin_init_abi): Add comment, call cygwin_init_abi.
        * i386-windows-tdep.c (i386_windows_init_abi): Rename to
        i386_windows_init_abi_common, don't call windows_init_abi.  Add
        a new function of this name.
        (i386_cygwin_init_abi): New function.
        (_initialize_i386_windows_tdep): Bind i386_cygwin_init_abi to
        OS ABI Cygwin.
---
 gdb/amd64-windows-tdep.c |  10 +-
 gdb/i386-windows-tdep.c  |  27 ++++-
 gdb/windows-tdep.c       | 214 ++++++++++++++++++++++++++-------------
 gdb/windows-tdep.h       |   9 ++
 4 files changed, 181 insertions(+), 79 deletions(-)

diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c
index 6d5076d1c437..740152b7de8e 100644
--- a/gdb/amd64-windows-tdep.c
+++ b/gdb/amd64-windows-tdep.c
@@ -1208,6 +1208,8 @@ amd64_windows_auto_wide_charset (void)
   return "UTF-16";
 }

+/* Common parts for gdbarch initialization for Windows and Cygwin on AMD64.  */
+
 static void
 amd64_windows_init_abi_common (gdbarch_info info, struct gdbarch *gdbarch)
 {
@@ -1227,8 +1229,6 @@ amd64_windows_init_abi_common (gdbarch_info info, struct gdbarch *gdbarch)
   amd64_init_abi (info, gdbarch,
   amd64_target_description (X86_XSTATE_SSE_MASK, false));

-  windows_init_abi (info, gdbarch);
-
   /* Function calls.  */
   set_gdbarch_push_dummy_call (gdbarch, amd64_windows_push_dummy_call);
   set_gdbarch_return_value (gdbarch, amd64_windows_return_value);
@@ -1241,19 +1241,25 @@ amd64_windows_init_abi_common (gdbarch_info info, struct gdbarch *gdbarch)
   set_gdbarch_auto_wide_charset (gdbarch, amd64_windows_auto_wide_charset);
 }

+/* gdbarch initialization for Windows on AMD64.  */
+
 static void
 amd64_windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   amd64_windows_init_abi_common (info, gdbarch);
+  windows_init_abi (info, gdbarch);

   /* On Windows, "long"s are only 32bit.  */
   set_gdbarch_long_bit (gdbarch, 32);
 }

+/* gdbarch initialization for Cygwin on AMD64.  */
+
 static void
 amd64_cygwin_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   amd64_windows_init_abi_common (info, gdbarch);
+  cygwin_init_abi (info, gdbarch);
 }

 static gdb_osabi
diff --git a/gdb/i386-windows-tdep.c b/gdb/i386-windows-tdep.c
index b26731c6bf28..3a07c862f233 100644
--- a/gdb/i386-windows-tdep.c
+++ b/gdb/i386-windows-tdep.c
@@ -200,13 +200,13 @@ i386_windows_auto_wide_charset (void)
   return "UTF-16";
 }

+/* Common parts for gdbarch initialization for Windows and Cygwin on i386.  */
+
 static void
-i386_windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+i386_windows_init_abi_common (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);

-  windows_init_abi (info, gdbarch);
-
   set_gdbarch_skip_trampoline_code (gdbarch, i386_windows_skip_trampoline_code);

   set_gdbarch_skip_main_prologue (gdbarch, i386_skip_main_prologue);
@@ -227,6 +227,24 @@ i386_windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   set_gdbarch_auto_wide_charset (gdbarch, i386_windows_auto_wide_charset);
 }

+/* gdbarch initialization for Windows on i386.  */
+
+static void
+i386_windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  i386_windows_init_abi_common (info, gdbarch);
+  windows_init_abi (info, gdbarch);
+}
+
+/* gdbarch initialization for Cygwin on i386.  */
+
+static void
+i386_cygwin_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  i386_windows_init_abi_common (info, gdbarch);
+  cygwin_init_abi (info, gdbarch);
+}
+
 static gdb_osabi
 i386_windows_osabi_sniffer (bfd *abfd)
 {
@@ -270,9 +288,8 @@ _initialize_i386_windows_tdep ()
   gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_elf_flavour,
                                   i386_cygwin_core_osabi_sniffer);

-  /* The Windows and Cygwin OS ABIs are currently equivalent on i386.  */
   gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_WINDOWS,
                           i386_windows_init_abi);
   gdbarch_register_osabi (bfd_arch_i386, 0, GDB_OSABI_CYGWIN,
-                          i386_windows_init_abi);
+  i386_cygwin_init_abi);
 }
diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
index 0042ea350e80..9c5dfd183bfa 100644
--- a/gdb/windows-tdep.c
+++ b/gdb/windows-tdep.c
@@ -41,55 +41,69 @@
 #define CYGWIN_DLL_NAME "cygwin1.dll"

 /* Windows signal numbers differ between MinGW flavors and between
-   those and Cygwin.  The below enumeration was gleaned from the
-   respective headers; the ones marked with MinGW64/Cygwin are defined
-   only by MinGW64 and Cygwin, not by mingw.org's MinGW.  FIXME: We
-   should really have distinct MinGW vs Cygwin OSABIs, and two
-   separate enums, selected at runtime.  */
+   those and Cygwin.  The below enumerations were gleaned from the
+   respective headers.  */
+
+/* Signal numbers for the various MinGW flavors.  The ones marked with
+   MinGW-w64 are defined by MinGW-w64, not by mingw.org's MinGW.  */

 enum
-  {
-   WINDOWS_SIGHUP = 1, /* MinGW64/Cygwin */
-   WINDOWS_SIGINT = 2,
-   WINDOWS_SIGQUIT = 3, /* MinGW64/Cygwin */
-   WINDOWS_SIGILL = 4,
-   WINDOWS_SIGTRAP = 5, /* MinGW64/Cygwin */
-#ifdef __CYGWIN__
-   WINDOWS_SIGABRT = 6,
-#else
-   WINDOWS_SIGIOT = 6, /* MinGW64 */
-#endif
-   WINDOWS_SIGEMT = 7, /* MinGW64/Cygwin */
-   WINDOWS_SIGFPE = 8,
-   WINDOWS_SIGKILL = 9, /* MinGW64/Cygwin */
-   WINDOWS_SIGBUS = 10, /* MinGW64/Cygwin */
-   WINDOWS_SIGSEGV = 11,
-   WINDOWS_SIGSYS = 12, /* MinGW64/Cygwin */
-   WINDOWS_SIGPIPE = 13,/* MinGW64/Cygwin */
-   WINDOWS_SIGALRM = 14,/* MinGW64/Cygwin */
-   WINDOWS_SIGTERM = 15,
-#ifdef __CYGWIN__
-   WINDOWS_SIGURG = 16,
-   WINDOWS_SIGSTOP = 17,
-   WINDOWS_SIGTSTP = 18,
-   WINDOWS_SIGCONT = 19,
-   WINDOWS_SIGCHLD = 20,
-   WINDOWS_SIGTTIN = 21,
-   WINDOWS_SIGTTOU = 22,
-   WINDOWS_SIGIO = 23,
-   WINDOWS_SIGXCPU = 24,
-   WINDOWS_SIGXFSZ = 25,
-   WINDOWS_SIGVTALRM = 26,
-   WINDOWS_SIGPROF = 27,
-   WINDOWS_SIGWINCH = 28,
-   WINDOWS_SIGLOST = 29,
-   WINDOWS_SIGUSR1 = 30,
-   WINDOWS_SIGUSR2 = 31
-#else
-   WINDOWS_SIGBREAK = 21,
-   WINDOWS_SIGABRT = 22
-#endif
-  };
+{
+  WINDOWS_SIGHUP = 1, /* MinGW-w64 */
+  WINDOWS_SIGINT = 2,
+  WINDOWS_SIGQUIT = 3, /* MinGW-w64 */
+  WINDOWS_SIGILL = 4,
+  WINDOWS_SIGTRAP = 5, /* MinGW-w64 */
+  WINDOWS_SIGIOT = 6, /* MinGW-w64 */
+  WINDOWS_SIGEMT = 7, /* MinGW-w64 */
+  WINDOWS_SIGFPE = 8,
+  WINDOWS_SIGKILL = 9, /* MinGW-w64 */
+  WINDOWS_SIGBUS = 10, /* MinGW-w64 */
+  WINDOWS_SIGSEGV = 11,
+  WINDOWS_SIGSYS = 12, /* MinGW-w64 */
+  WINDOWS_SIGPIPE = 13, /* MinGW-w64 */
+  WINDOWS_SIGALRM = 14, /* MinGW-w64 */
+  WINDOWS_SIGTERM = 15,
+  WINDOWS_SIGBREAK = 21,
+  WINDOWS_SIGABRT = 22,
+};
+
+/* Signal numbers for Cygwin.  */
+
+enum
+{
+  CYGWIN_SIGHUP = 1,
+  CYGWIN_SIGINT = 2,
+  CYGWIN_SIGQUIT = 3,
+  CYGWIN_SIGILL = 4,
+  CYGWIN_SIGTRAP = 5,
+  CYGWIN_SIGABRT = 6,
+  CYGWIN_SIGEMT = 7,
+  CYGWIN_SIGFPE = 8,
+  CYGWIN_SIGKILL = 9,
+  CYGWIN_SIGBUS = 10,
+  CYGWIN_SIGSEGV = 11,
+  CYGWIN_SIGSYS = 12,
+  CYGWIN_SIGPIPE = 13,
+  CYGWIN_SIGALRM = 14,
+  CYGWIN_SIGTERM = 15,
+  CYGWIN_SIGURG = 16,
+  CYGWIN_SIGSTOP = 17,
+  CYGWIN_SIGTSTP = 18,
+  CYGWIN_SIGCONT = 19,
+  CYGWIN_SIGCHLD = 20,
+  CYGWIN_SIGTTIN = 21,
+  CYGWIN_SIGTTOU = 22,
+  CYGWIN_SIGIO = 23,
+  CYGWIN_SIGXCPU = 24,
+  CYGWIN_SIGXFSZ = 25,
+  CYGWIN_SIGVTALRM = 26,
+  CYGWIN_SIGPROF = 27,
+  CYGWIN_SIGWINCH = 28,
+  CYGWIN_SIGLOST = 29,
+  CYGWIN_SIGUSR1 = 30,
+  CYGWIN_SIGUSR2 = 31,
+};

 struct cmd_list_element *info_w32_cmdlist;

@@ -607,7 +621,7 @@ init_w32_command_list (void)
     }
 }

-/* Implementation of `gdbarch_gdb_signal_to_target'.  */
+/* Implementation of `gdbarch_gdb_signal_to_target' for Windows.  */

 static int
 windows_gdb_signal_to_target (struct gdbarch *gdbarch, enum gdb_signal signal)
@@ -646,40 +660,81 @@ windows_gdb_signal_to_target (struct gdbarch *gdbarch, enum gdb_signal signal)
       return WINDOWS_SIGALRM;
     case GDB_SIGNAL_TERM:
       return WINDOWS_SIGTERM;
-#ifdef __CYGWIN__
+    }
+  return -1;
+}
+
+/* Implementation of `gdbarch_gdb_signal_to_target' for Cygwin.  */
+
+static int
+cygwin_gdb_signal_to_target (struct gdbarch *gdbarch, enum gdb_signal signal)
+{
+  switch (signal)
+    {
+    case GDB_SIGNAL_0:
+      return 0;
+    case GDB_SIGNAL_HUP:
+      return CYGWIN_SIGHUP;
+    case GDB_SIGNAL_INT:
+      return CYGWIN_SIGINT;
+    case GDB_SIGNAL_QUIT:
+      return CYGWIN_SIGQUIT;
+    case GDB_SIGNAL_ILL:
+      return CYGWIN_SIGILL;
+    case GDB_SIGNAL_TRAP:
+      return CYGWIN_SIGTRAP;
+    case GDB_SIGNAL_ABRT:
+      return CYGWIN_SIGABRT;
+    case GDB_SIGNAL_EMT:
+      return CYGWIN_SIGEMT;
+    case GDB_SIGNAL_FPE:
+      return CYGWIN_SIGFPE;
+    case GDB_SIGNAL_KILL:
+      return CYGWIN_SIGKILL;
+    case GDB_SIGNAL_BUS:
+      return CYGWIN_SIGBUS;
+    case GDB_SIGNAL_SEGV:
+      return CYGWIN_SIGSEGV;
+    case GDB_SIGNAL_SYS:
+      return CYGWIN_SIGSYS;
+    case GDB_SIGNAL_PIPE:
+      return CYGWIN_SIGPIPE;
+    case GDB_SIGNAL_ALRM:
+      return CYGWIN_SIGALRM;
+    case GDB_SIGNAL_TERM:
+      return CYGWIN_SIGTERM;
     case GDB_SIGNAL_URG:
-      return WINDOWS_SIGURG;
+      return CYGWIN_SIGURG;
     case GDB_SIGNAL_STOP:
-      return WINDOWS_SIGSTOP;
+      return CYGWIN_SIGSTOP;
     case GDB_SIGNAL_TSTP:
-      return WINDOWS_SIGTSTP;
+      return CYGWIN_SIGTSTP;
     case GDB_SIGNAL_CONT:
-      return WINDOWS_SIGCONT;
+      return CYGWIN_SIGCONT;
     case GDB_SIGNAL_CHLD:
-      return WINDOWS_SIGCHLD;
+      return CYGWIN_SIGCHLD;
     case GDB_SIGNAL_TTIN:
-      return WINDOWS_SIGTTIN;
+      return CYGWIN_SIGTTIN;
     case GDB_SIGNAL_TTOU:
-      return WINDOWS_SIGTTOU;
+      return CYGWIN_SIGTTOU;
     case GDB_SIGNAL_IO:
-      return WINDOWS_SIGIO;
+      return CYGWIN_SIGIO;
     case GDB_SIGNAL_XCPU:
-      return WINDOWS_SIGXCPU;
+      return CYGWIN_SIGXCPU;
     case GDB_SIGNAL_XFSZ:
-      return WINDOWS_SIGXFSZ;
+      return CYGWIN_SIGXFSZ;
     case GDB_SIGNAL_VTALRM:
-      return WINDOWS_SIGVTALRM;
+      return CYGWIN_SIGVTALRM;
     case GDB_SIGNAL_PROF:
-      return WINDOWS_SIGPROF;
+      return CYGWIN_SIGPROF;
     case GDB_SIGNAL_WINCH:
-      return WINDOWS_SIGWINCH;
+      return CYGWIN_SIGWINCH;
     case GDB_SIGNAL_PWR:
-      return WINDOWS_SIGLOST;
+      return CYGWIN_SIGLOST;
     case GDB_SIGNAL_USR1:
-      return WINDOWS_SIGUSR1;
+      return CYGWIN_SIGUSR1;
     case GDB_SIGNAL_USR2:
-      return WINDOWS_SIGUSR2;
-#endif /* __CYGWIN__ */
+      return CYGWIN_SIGUSR2;
     }
   return -1;
 }
@@ -865,11 +920,11 @@ windows_solib_create_inferior_hook (int from_tty)

 static struct target_so_ops windows_so_ops;

-/* To be called from the various GDB_OSABI_CYGWIN handlers for the
-   various Windows architectures and machine types.  */
+/* Common parts for gdbarch initialization for the Windows and Cygwin OS
+   ABIs.  */

-void
-windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+static void
+windows_init_abi_common (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   set_gdbarch_wchar_bit (gdbarch, 16);
   set_gdbarch_wchar_signed (gdbarch, 0);
@@ -881,8 +936,6 @@ windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   set_gdbarch_iterate_over_objfiles_in_search_order
     (gdbarch, windows_iterate_over_objfiles_in_search_order);

-  set_gdbarch_gdb_signal_to_target (gdbarch, windows_gdb_signal_to_target);
-
   windows_so_ops = solib_target_so_ops;
   windows_so_ops.solib_create_inferior_hook
     = windows_solib_create_inferior_hook;
@@ -891,6 +944,23 @@ windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   set_gdbarch_get_siginfo_type (gdbarch, windows_get_siginfo_type);
 }

+/* See windows-tdep.h.  */
+void
+windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  windows_init_abi_common (info, gdbarch);
+  set_gdbarch_gdb_signal_to_target (gdbarch, windows_gdb_signal_to_target);
+}
+
+/* See windows-tdep.h.  */
+
+void
+cygwin_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  windows_init_abi_common (info, gdbarch);
+  set_gdbarch_gdb_signal_to_target (gdbarch, cygwin_gdb_signal_to_target);
+}
+
 /* Implementation of `tlb' variable.  */

 static const struct internalvar_funcs tlb_funcs =
diff --git a/gdb/windows-tdep.h b/gdb/windows-tdep.h
index f2dc4260469d..cd7717bd9174 100644
--- a/gdb/windows-tdep.h
+++ b/gdb/windows-tdep.h
@@ -31,9 +31,18 @@ extern void windows_xfer_shared_library (const char* so_name,
  struct gdbarch *gdbarch,
  struct obstack *obstack);

+/* To be called from the various GDB_OSABI_WINDOWS handlers for the
+   various Windows architectures and machine types.  */
+
 extern void windows_init_abi (struct gdbarch_info info,
       struct gdbarch *gdbarch);

+/* To be called from the various GDB_OSABI_CYGWIN handlers for the
+   various Windows architectures and machine types.  */
+
+extern void cygwin_init_abi (struct gdbarch_info info,
+     struct gdbarch *gdbarch);
+
 /* Return true if the Portable Executable behind ABFD uses the Cygwin dll
    (cygwin1.dll).  */

--
2.26.0

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries

Tom Tromey-2
In reply to this post by Sourceware - gdb-patches mailing list
While reading Pedro's note I noticed:

>> +  const gdb_byte *const idata_contents
>> +    = gdb_bfd_map_section (idata_section, &idata_size);

There's no way to ever release this data.  Since it's only used once, it
may be better to use bfd_get_full_section_contents, so the memory can be
freed when done.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries

Sourceware - gdb-patches mailing list
In reply to this post by Sourceware - gdb-patches mailing list
On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote:

> On 2020-04-01 5:36 p.m., Pedro Alves wrote:
>> On 3/16/20 5:08 PM, Simon Marchi via Gdb-patches wrote:
>>> +bool
>>> +is_linked_with_cygwin_dll (bfd *abfd)
>>> +{
>>> +  /* The list of DLLs a PE is linked to is in the .idata section.  See:
>>> +
>>> +     https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section
>>> +   */
>>> +  asection *idata_section = bfd_get_section_by_name (abfd, ".idata");
>>> +  if (idata_section == nullptr)
>>> +    return false;
>>> +
>>> +  /* Find the virtual address of the .idata section.  We must subtract this
>>> +     from the RVAs (relative virtual addresses) to obtain an offset in the
>>> +     section. */
>>> +  bfd_vma idata_addr =
>>> +    pe_data (abfd)->pe_opthdr.DataDirectory[PE_IMPORT_TABLE].VirtualAddress;
>>
>> = on next line.  Unless it doesn't fit, then let's ignore.
>
> Yes it fits.
>>> +
>>> +  /* Map the section's data.  */
>>> +  bfd_size_type idata_size;
>>> +  const gdb_byte *const idata_contents
>>> +    = gdb_bfd_map_section (idata_section, &idata_size);
>>> +  if (idata_contents == nullptr)
>>> +    {
>>> +      warning (_("Failed to get content of .idata section."));
>>> +      return false;
>>> +    }
>>> +
>>> +  const gdb_byte *iter = idata_contents;
>>> +  const gdb_byte *end = idata_contents + idata_size;
>>> +  const pe_import_directory_entry null_dir_entry = { 0 };
>>> +
>>> +  /* Iterate through all directory entries.  */
>>> +  while (true)
>>> +    {
>>> +      /* Is there enough space left in the section for another entry?  */
>>> +      if (iter + sizeof (pe_import_directory_entry) > end)
>>> + {
>>> +  warning (_("Failed to parse .idata section: unexpected end of "
>>> +     ".idata section."));
>>> +  break;
>>> + }
>>> +
>>> +      pe_import_directory_entry *dir_entry = (pe_import_directory_entry *) iter;
>>
>> Is 'iter' guaranteed to be sufficiently aligned?  Recall that this is
>> host-independent code.
>
> I admit I haven't thought about that.  Within the PE file, the data of sections is
> aligned on at least 512 bytes.  See "FileAlignment" here:
>
> https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#optional-header-windows-specific-fields-image-only

Ah, good.  Sounds like the data structures were designed for
memory mapping.  Which isn't that surprising.

>
> However, when BFD maps the file/section data in memory for GDB to read, is that mapping
> guaranteed to be sufficiently aligned as well?

I think so.  If bfd heap allocates, then memory will be aligned to the word size at
least.  If bfd mmaps, then memory will be aligned to page size.  And then if the
data structures are aligned, we should be good.

Thanks,
Pedro Alves

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: stop using host-dependent signal numbers in, windows-tdep.c

Sourceware - gdb-patches mailing list
In reply to this post by Simon Marchi-4
On 4/2/20 4:06 AM, Simon Marchi wrote:
> On 2020-04-01 5:56 p.m., Simon Marchi via Gdb-patches wrote:

>> Ok, I'll see what I can do.
>
> Here's a patch that does that.  Note that I have only built-tested it.  I'm so
> inefficient with Windows that if I wait until I have the time to actually try
> it, I'll never get it done.  So I'm hoping that the Windows gurus can give it
> a look.

Wow, thanks for doing this.  Most excellent.

It looks good to me.

Thanks,
Pedro Alves

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries

Sourceware - gdb-patches mailing list
In reply to this post by Sourceware - gdb-patches mailing list
On 2020-04-02 9:56 a.m., Pedro Alves wrote:
> On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote:
>> However, when BFD maps the file/section data in memory for GDB to read, is that mapping
>> guaranteed to be sufficiently aligned as well?
>
> I think so.  If bfd heap allocates, then memory will be aligned to the word size at
> least.  If bfd mmaps, then memory will be aligned to page size.  And then if the
> data structures are aligned, we should be good.

Following this message from Tom [1], I'm going to change the code to use
bfd_get_full_section_contents and store the data into a pre-allocated gdb::byte_vector.
Does that change anything?

[1] https://marc.info/?l=gdb-patches&m=158583388704648&w=2

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: stop using host-dependent signal numbers in, windows-tdep.c

Simon Marchi-4
In reply to this post by Sourceware - gdb-patches mailing list
On 2020-04-02 10:00 a.m., Pedro Alves wrote:

> On 4/2/20 4:06 AM, Simon Marchi wrote:
>> On 2020-04-01 5:56 p.m., Simon Marchi via Gdb-patches wrote:
>
>>> Ok, I'll see what I can do.
>>
>> Here's a patch that does that.  Note that I have only built-tested it.  I'm so
>> inefficient with Windows that if I wait until I have the time to actually try
>> it, I'll never get it done.  So I'm hoping that the Windows gurus can give it
>> a look.
>
> Wow, thanks for doing this.  Most excellent.
>
> It looks good to me.
>
> Thanks,
> Pedro Alves

Thanks.  I'll give some time to Jon and/or Eli to take a look before pushing.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries

Sourceware - gdb-patches mailing list
In reply to this post by Sourceware - gdb-patches mailing list
On 4/2/20 3:01 PM, Simon Marchi wrote:

> On 2020-04-02 9:56 a.m., Pedro Alves wrote:
>> On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote:
>>> However, when BFD maps the file/section data in memory for GDB to read, is that mapping
>>> guaranteed to be sufficiently aligned as well?
>>
>> I think so.  If bfd heap allocates, then memory will be aligned to the word size at
>> least.  If bfd mmaps, then memory will be aligned to page size.  And then if the
>> data structures are aligned, we should be good.
>
> Following this message from Tom [1], I'm going to change the code to use
> bfd_get_full_section_contents and store the data into a pre-allocated gdb::byte_vector.
> Does that change anything?

I don't think it does.

Thanks,
Pedro Alves

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries

Sourceware - gdb-patches mailing list
On 2020-04-02 10:03 a.m., Pedro Alves wrote:

> On 4/2/20 3:01 PM, Simon Marchi wrote:
>> On 2020-04-02 9:56 a.m., Pedro Alves wrote:
>>> On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote:
>>>> However, when BFD maps the file/section data in memory for GDB to read, is that mapping
>>>> guaranteed to be sufficiently aligned as well?
>>>
>>> I think so.  If bfd heap allocates, then memory will be aligned to the word size at
>>> least.  If bfd mmaps, then memory will be aligned to page size.  And then if the
>>> data structures are aligned, we should be good.
>>
>> Following this message from Tom [1], I'm going to change the code to use
>> bfd_get_full_section_contents and store the data into a pre-allocated gdb::byte_vector.
>> Does that change anything?
>
> I don't think it does.

Err, just to make a correction: bfd_get_full_section_contents allocates the memory itself
and returns a pointer, so I won't use gdb::byte_vector.  Since BFD does the allocation
itself, then we can say it's responsible for returning a properly aligned buffer.

Simon

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries

Sourceware - gdb-patches mailing list
On 2020-04-02 10:08 a.m., Simon Marchi wrote:

> On 2020-04-02 10:03 a.m., Pedro Alves wrote:
>> On 4/2/20 3:01 PM, Simon Marchi wrote:
>>> On 2020-04-02 9:56 a.m., Pedro Alves wrote:
>>>> On 4/1/20 10:53 PM, Simon Marchi via Gdb-patches wrote:
>>>>> However, when BFD maps the file/section data in memory for GDB to read, is that mapping
>>>>> guaranteed to be sufficiently aligned as well?
>>>>
>>>> I think so.  If bfd heap allocates, then memory will be aligned to the word size at
>>>> least.  If bfd mmaps, then memory will be aligned to page size.  And then if the
>>>> data structures are aligned, we should be good.
>>>
>>> Following this message from Tom [1], I'm going to change the code to use
>>> bfd_get_full_section_contents and store the data into a pre-allocated gdb::byte_vector.
>>> Does that change anything?
>>
>> I don't think it does.
>
> Err, just to make a correction: bfd_get_full_section_contents allocates the memory itself
> and returns a pointer, so I won't use gdb::byte_vector.  Since BFD does the allocation
> itself, then we can say it's responsible for returning a properly aligned buffer.

Scratch that again.  I now realized that bfd_get_section_contents uses a user-provided buffer,
unlike bfd_get_full_section_contents.  I am not sure yet what I'm going to use.

Simon
Reply | Threaded
Open this post in threaded view
|

[PATCH] gdb: use bfd_get_section_contents to read section contents in, is_linked_with_cygwin_dll (was: Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries)

Sourceware - gdb-patches mailing list
In reply to this post by Tom Tromey-2
On 2020-04-02 9:22 a.m., Tom Tromey wrote:
> There's no way to ever release this data.  Since it's only used once, it
> may be better to use bfd_get_full_section_contents, so the memory can be
> freed when done.

Good point, I hadn't thought of that.

Here's a patch.  I only tested it on GNU/Linux, making sure GDB is still able
to recognize a mingw binary and a cygwin binary.


From b7f4f941018c7b4a7431837ccf5eee5c992f4111 Mon Sep 17 00:00:00 2001
From: Simon Marchi <[hidden email]>
Date: Thu, 2 Apr 2020 10:34:39 -0400
Subject: [PATCH] gdb: use bfd_get_section_contents to read section contents in
 is_linked_with_cygwin_dll

The function is_linked_with_cygwin_dll currently uses
gdb_bfd_map_section to get some section contents.  This is not ideal
because that memory, which is only used in this function, can't be
released.  Instead, it was suggested to use bfd_get_section_contents,
and this is what this patch does.

I decided to make a small bfd_get_section_contents wrapper in gdb_bfd.c,
which returns the contents in a gdb::byte_vector.  The wrapper also
makes it easy to get the full section contents into a gdb::byte_vector.
Note that BFD provides the bfd_get_full_section_contents function, but
this one returns a newly-allocated buffer.  gdb_bfd_get_section_contents
offers a consistent interface, regardless of whether you need to read
part of a section or the full section.

gdb_bfd_get_section_contents could be used at many places that already
allocate a vector of the size of the section and then call
bfd_get_section_contents.  I think these call sites can be updated over
time.

gdb/ChangeLog:

        * gdb_bfd.h: Include gdbsupport/byte-vector.h and
        gdbsupport/gdb_optional.h.
        (BFD_SIZE_TYPE_MAX): New macro.
        (gdb_bfd_get_section_contents): New declaration.
        * gdb_bfd.c (gdb_bfd_get_section_contents): New function.
        * windows-tdep.c (is_linked_with_cygwin_dll): Use
        gdb_bfd_get_section_contents.
---
 gdb/gdb_bfd.c      | 25 ++++++++++++++++++++++++-
 gdb/gdb_bfd.h      | 15 +++++++++++++++
 gdb/windows-tdep.c | 13 ++++++-------
 3 files changed, 45 insertions(+), 8 deletions(-)

diff --git a/gdb/gdb_bfd.c b/gdb/gdb_bfd.c
index 5a6dee2d51a8..2b34e0f3e17c 100644
--- a/gdb/gdb_bfd.c
+++ b/gdb/gdb_bfd.c
@@ -926,7 +926,30 @@ gdb_bfd_requires_relocations (bfd *abfd)
   return gdata->needs_relocations;
 }

-
+/* See gdb_bfd.h.  */
+
+bool
+gdb_bfd_get_section_contents (bfd *abfd, asection *section,
+      gdb::byte_vector *contents, file_ptr offset,
+      bfd_size_type count)
+{
+  bfd_size_type section_size = bfd_section_size (section);
+
+  /* Allow `offset == section_size`, to allow the corner case of
+     `offset == section_size`, `count = 0`.  */
+  gdb_assert (offset <= section_size);
+
+  /* If COUNT is unspecified, get the contents from OFFSET until the end of the
+     section.  */
+  if (count == BFD_SIZE_TYPE_MAX)
+    count = section_size - offset;
+
+  gdb_assert ((offset + count) <= section_size);
+
+  contents->resize (count);
+
+  return bfd_get_section_contents (abfd, section, contents->data (), offset, count);
+}

 /* A callback for htab_traverse that prints a single BFD.  */

diff --git a/gdb/gdb_bfd.h b/gdb/gdb_bfd.h
index 9b1e292bf18f..ffea4f6b715e 100644
--- a/gdb/gdb_bfd.h
+++ b/gdb/gdb_bfd.h
@@ -21,6 +21,8 @@
 #define GDB_BFD_H

 #include "registry.h"
+#include "gdbsupport/byte-vector.h"
+#include "gdbsupport/gdb_optional.h"
 #include "gdbsupport/gdb_ref_ptr.h"

 DECLARE_REGISTRY (bfd);
@@ -30,6 +32,8 @@ DECLARE_REGISTRY (bfd);

 #define TARGET_SYSROOT_PREFIX "target:"

+#define BFD_SIZE_TYPE_MAX ((bfd_size_type) -1)
+
 /* Returns nonzero if NAME starts with TARGET_SYSROOT_PREFIX, zero
    otherwise.  */

@@ -181,4 +185,15 @@ int gdb_bfd_count_sections (bfd *abfd);

 int gdb_bfd_requires_relocations (bfd *abfd);

+/* Wrapper around bfd_get_section_contents, returning the requested section
+   contents in *CONTENTS.  Return true on success, false otherwise.
+
+   If COUNT is not specified, read from OFFSET until the end of the
+   section.  */
+
+bool
+gdb_bfd_get_section_contents (bfd *abfd, asection *section,
+      gdb::byte_vector *contents, file_ptr offset = 0,
+      bfd_size_type count = BFD_SIZE_TYPE_MAX);
+
 #endif /* GDB_BFD_H */
diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
index 9c5dfd183bfa..9b7dc1d12b26 100644
--- a/gdb/windows-tdep.c
+++ b/gdb/windows-tdep.c
@@ -1005,18 +1005,17 @@ is_linked_with_cygwin_dll (bfd *abfd)
   bfd_vma idata_addr
     = pe_data (abfd)->pe_opthdr.DataDirectory[PE_IMPORT_TABLE].VirtualAddress;

-  /* Map the section's data.  */
-  bfd_size_type idata_size;
-  const gdb_byte *const idata_contents
-    = gdb_bfd_map_section (idata_section, &idata_size);
-  if (idata_contents == nullptr)
+  /* Get the section's data.  */
+  gdb::byte_vector idata_contents;
+  if (!gdb_bfd_get_section_contents(abfd, idata_section, &idata_contents))
     {
       warning (_("Failed to get content of .idata section."));
       return false;
     }

-  const gdb_byte *iter = idata_contents;
-  const gdb_byte *end = idata_contents + idata_size;
+  size_t idata_size = idata_contents.size ();
+  const gdb_byte *iter = idata_contents.data ();
+  const gdb_byte *end = idata_contents.data () + idata_size;
   const pe_import_directory_entry null_dir_entry = { 0 };

   /* Iterate through all directory entries.  */
--
2.26.0


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: use bfd_get_section_contents to read section contents in, is_linked_with_cygwin_dll

Simon Marchi-4
On 2020-04-02 10:55 a.m., Simon Marchi via Gdb-patches wrote:

> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
> index 9c5dfd183bfa..9b7dc1d12b26 100644
> --- a/gdb/windows-tdep.c
> +++ b/gdb/windows-tdep.c
> @@ -1005,18 +1005,17 @@ is_linked_with_cygwin_dll (bfd *abfd)
>    bfd_vma idata_addr
>      = pe_data (abfd)->pe_opthdr.DataDirectory[PE_IMPORT_TABLE].VirtualAddress;
>
> -  /* Map the section's data.  */
> -  bfd_size_type idata_size;
> -  const gdb_byte *const idata_contents
> -    = gdb_bfd_map_section (idata_section, &idata_size);
> -  if (idata_contents == nullptr)
> +  /* Get the section's data.  */
> +  gdb::byte_vector idata_contents;
> +  if (!gdb_bfd_get_section_contents(abfd, idata_section, &idata_contents))

Missing space here, consider it fixed.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: stop using host-dependent signal numbers in, windows-tdep.c

Eli Zaretskii
In reply to this post by Simon Marchi-4
> From: Simon Marchi <[hidden email]>
> Date: Thu, 2 Apr 2020 10:02:48 -0400
> Cc: Jon Turney <[hidden email]>
>
> > Wow, thanks for doing this.  Most excellent.
> >
> > It looks good to me.
> >
> > Thanks,
> > Pedro Alves
>
> Thanks.  I'll give some time to Jon and/or Eli to take a look before pushing.

LGTM, thanks.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: use bfd_get_section_contents to read section contents in, is_linked_with_cygwin_dll

Tom Tromey-2
In reply to this post by Sourceware - gdb-patches mailing list
>>>>> "Simon" == Simon Marchi <[hidden email]> writes:

Simon> +  return bfd_get_section_contents (abfd, section, contents->data (), offset, count);

This line looks too long.

Simon> +/* Wrapper around bfd_get_section_contents, returning the requested section
Simon> +   contents in *CONTENTS.  Return true on success, false otherwise.
Simon> +
Simon> +   If COUNT is not specified, read from OFFSET until the end of the
Simon> +   section.  */
Simon> +
Simon> +bool
Simon> +gdb_bfd_get_section_contents (bfd *abfd, asection *section,

Normally in .h files we don't put a newline after the type.

Simon> +  gdb::byte_vector idata_contents;
Simon> +  if (!gdb_bfd_get_section_contents(abfd, idata_section, &idata_contents))

Space before paren.

Otherwise this looks good.  Thank you for doing this.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: use bfd_get_section_contents to read section contents in, is_linked_with_cygwin_dll

Sourceware - gdb-patches mailing list
On 2020-04-02 3:01 p.m., Tom Tromey wrote:

>>>>>> "Simon" == Simon Marchi <[hidden email]> writes:
>
> Simon> +  return bfd_get_section_contents (abfd, section, contents->data (), offset, count);
>
> This line looks too long.
>
> Simon> +/* Wrapper around bfd_get_section_contents, returning the requested section
> Simon> +   contents in *CONTENTS.  Return true on success, false otherwise.
> Simon> +
> Simon> +   If COUNT is not specified, read from OFFSET until the end of the
> Simon> +   section.  */
> Simon> +
> Simon> +bool
> Simon> +gdb_bfd_get_section_contents (bfd *abfd, asection *section,
>
> Normally in .h files we don't put a newline after the type.
>
> Simon> +  gdb::byte_vector idata_contents;
> Simon> +  if (!gdb_bfd_get_section_contents(abfd, idata_section, &idata_contents))
>
> Space before paren.
>
> Otherwise this looks good.  Thank you for doing this.
>
> Tom

Now that I re-read it, I don't think the function should take the extra OFFSET and
COUNT parameters, since they are not used anywhere.  I went around our calls to
bfd_get_section_contents, and I don't think they would be very useful.  And I would
prefer not to check in code if it's not going to be exercised.

So I'd go with this simpler version instead.  The extra complexity can be added later,
if needed.

From 791b9d9d068cdf00795fd0d002e4058534099d4f Mon Sep 17 00:00:00 2001
From: Simon Marchi <[hidden email]>
Date: Thu, 2 Apr 2020 10:34:39 -0400
Subject: [PATCH] gdb: use bfd_get_section_contents to read section contents in
 is_linked_with_cygwin_dll

The function is_linked_with_cygwin_dll currently uses
gdb_bfd_map_section to get some section contents.  This is not ideal
because that memory, which is only used in this function, can't be
released.  Instead, it was suggested to use
bfd_get_full_section_contents.

However, bfd_get_full_section_contents returns a newly allocated buffer,
which is not very practical to use with C++ automatic memory management
constructs.  I decided to make gdb_bfd_get_full_section_contents, a
small alternative to bfd_get_full_section_contents.  It is a small
wrapper around bfd_get_section_contents which returns the full contents
of the section in a gdb::byte_vector.

gdb_bfd_get_full_section_contents could be used at many places that
already allocate a vector of the size of the section and then call
bfd_get_section_contents.  I think these call sites can be updated over
time.

gdb/ChangeLog:

        * gdb_bfd.h: Include gdbsupport/byte-vector.h.
        (gdb_bfd_get_full_section_contents): New declaration.
        * gdb_bfd.c (gdb_bfd_get_full_section_contents): New function.
        * windows-tdep.c (is_linked_with_cygwin_dll): Use
        gdb_bfd_get_full_section_contents.
---
 gdb/gdb_bfd.c      | 13 ++++++++++++-
 gdb/gdb_bfd.h      |  9 +++++++++
 gdb/windows-tdep.c | 13 ++++++-------
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/gdb/gdb_bfd.c b/gdb/gdb_bfd.c
index 5a6dee2d51a8..a538c461cc88 100644
--- a/gdb/gdb_bfd.c
+++ b/gdb/gdb_bfd.c
@@ -926,7 +926,18 @@ gdb_bfd_requires_relocations (bfd *abfd)
   return gdata->needs_relocations;
 }

-
+/* See gdb_bfd.h.  */
+
+bool
+gdb_bfd_get_full_section_contents (bfd *abfd, asection *section,
+   gdb::byte_vector *contents)
+{
+  bfd_size_type section_size = bfd_section_size (section);
+
+  contents->resize (section_size);
+
+  return bfd_get_section_contents (abfd, section, contents->data (), 0, section_size);
+}

 /* A callback for htab_traverse that prints a single BFD.  */

diff --git a/gdb/gdb_bfd.h b/gdb/gdb_bfd.h
index 9b1e292bf18f..ce72f78a23f3 100644
--- a/gdb/gdb_bfd.h
+++ b/gdb/gdb_bfd.h
@@ -21,6 +21,7 @@
 #define GDB_BFD_H

 #include "registry.h"
+#include "gdbsupport/byte-vector.h"
 #include "gdbsupport/gdb_ref_ptr.h"

 DECLARE_REGISTRY (bfd);
@@ -181,4 +182,12 @@ int gdb_bfd_count_sections (bfd *abfd);

 int gdb_bfd_requires_relocations (bfd *abfd);

+/* Alternative to bfd_get_full_section_contents that returns the section
+   contents in *CONTENTS, instead of an allocated buffer.
+
+   Return true on success, false otherwise.  */
+
+bool gdb_bfd_get_full_section_contents (bfd *abfd, asection *section,
+ gdb::byte_vector *contents);
+
 #endif /* GDB_BFD_H */
diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
index 0042ea350e80..662a46fe1d70 100644
--- a/gdb/windows-tdep.c
+++ b/gdb/windows-tdep.c
@@ -935,18 +935,17 @@ is_linked_with_cygwin_dll (bfd *abfd)
   bfd_vma idata_addr
     = pe_data (abfd)->pe_opthdr.DataDirectory[PE_IMPORT_TABLE].VirtualAddress;

-  /* Map the section's data.  */
-  bfd_size_type idata_size;
-  const gdb_byte *const idata_contents
-    = gdb_bfd_map_section (idata_section, &idata_size);
-  if (idata_contents == nullptr)
+  /* Get the section's data.  */
+  gdb::byte_vector idata_contents;
+  if (!gdb_bfd_get_full_section_contents (abfd, idata_section, &idata_contents))
     {
       warning (_("Failed to get content of .idata section."));
       return false;
     }

-  const gdb_byte *iter = idata_contents;
-  const gdb_byte *end = idata_contents + idata_size;
+  size_t idata_size = idata_contents.size ();
+  const gdb_byte *iter = idata_contents.data ();
+  const gdb_byte *end = idata_contents.data () + idata_size;
   const pe_import_directory_entry null_dir_entry = { 0 };

   /* Iterate through all directory entries.  */
--
2.26.0




Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: use bfd_get_section_contents to read section contents in, is_linked_with_cygwin_dll

Tom Tromey-2
>>>>> "Simon" == Simon Marchi via Gdb-patches <[hidden email]> writes:

Simon> +  return bfd_get_section_contents (abfd, section, contents->data (), offset, count);
>>
>> This line looks too long.

It's still too long in this version.

Simon> Now that I re-read it, I don't think the function should take the extra OFFSET and
Simon> COUNT parameters, since they are not used anywhere.  I went around our calls to
Simon> bfd_get_section_contents, and I don't think they would be very useful.  And I would
Simon> prefer not to check in code if it's not going to be exercised.

Simon> So I'd go with this simpler version instead.  The extra complexity can be added later,
Simon> if needed.

Sounds reasonable to me.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: use bfd_get_section_contents to read section contents in, is_linked_with_cygwin_dll

Sourceware - gdb-patches mailing list
On 2020-04-02 3:45 p.m., Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <[hidden email]> writes:
>
> Simon> +  return bfd_get_section_contents (abfd, section, contents->data (), offset, count);
>>>
>>> This line looks too long.
>
> It's still too long in this version.

Sorry, I missed that comment earlier.  Fixed now.

> Simon> Now that I re-read it, I don't think the function should take the extra OFFSET and
> Simon> COUNT parameters, since they are not used anywhere.  I went around our calls to
> Simon> bfd_get_section_contents, and I don't think they would be very useful.  And I would
> Simon> prefer not to check in code if it's not going to be exercised.
>
> Simon> So I'd go with this simpler version instead.  The extra complexity can be added later,
> Simon> if needed.
>
> Sounds reasonable to me.

Thanks, I'm pushing it with the above issue fixed.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: stop using host-dependent signal numbers in, windows-tdep.c

Jon TURNEY
In reply to this post by Simon Marchi-4
On 02/04/2020 15:02, Simon Marchi wrote:

> On 2020-04-02 10:00 a.m., Pedro Alves wrote:
>> On 4/2/20 4:06 AM, Simon Marchi wrote:
>>> On 2020-04-01 5:56 p.m., Simon Marchi via Gdb-patches wrote:
>>
>>>> Ok, I'll see what I can do.
>>>
>>> Here's a patch that does that.  Note that I have only built-tested it.  I'm so
>>> inefficient with Windows that if I wait until I have the time to actually try
>>> it, I'll never get it done.  So I'm hoping that the Windows gurus can give it
>>> a look.
>>
>> Wow, thanks for doing this.  Most excellent.
>>
>> It looks good to me.
>>
>> Thanks,
>> Pedro Alves
>
> Thanks.  I'll give some time to Jon and/or Eli to take a look before pushing.

I don't see any problems with this.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] gdb: stop using host-dependent signal numbers in, windows-tdep.c

Simon Marchi-4
On 2020-04-08 8:45 a.m., Jon Turney wrote:

> On 02/04/2020 15:02, Simon Marchi wrote:
>> On 2020-04-02 10:00 a.m., Pedro Alves wrote:
>>> On 4/2/20 4:06 AM, Simon Marchi wrote:
>>>> On 2020-04-01 5:56 p.m., Simon Marchi via Gdb-patches wrote:
>>>
>>>>> Ok, I'll see what I can do.
>>>>
>>>> Here's a patch that does that.  Note that I have only built-tested it.  I'm so
>>>> inefficient with Windows that if I wait until I have the time to actually try
>>>> it, I'll never get it done.  So I'm hoping that the Windows gurus can give it
>>>> a look.
>>>
>>> Wow, thanks for doing this.  Most excellent.
>>>
>>> It looks good to me.
>>>
>>> Thanks,
>>> Pedro Alves
>>
>> Thanks.  I'll give some time to Jon and/or Eli to take a look before pushing.
>
> I don't see any problems with this.
>

Thanks, I pushed it.

Simon
12