[4/7] Add sniffer for Cygwin x86_64 core dumps

Message ID 20200701213225.14144-5-jon.turney@dronecode.org.uk
State New
Headers show
Series
  • Add gdb support for Cygwin x86_64 core dumps
Related show

Commit Message

Jon Turney July 1, 2020, 9:32 p.m.
Similarly to existing i386_cygwin_core_osabi_sniffer()

gdb/ChangeLog:

2020-07-01  Jon Turney  <jon.turney@dronecode.org.uk>

	* amd64-windows-tdep.c (amd64_cygwin_core_osabi_sniffer): New.
	(_initialize_amd64_windows_tdep): Register amd64_cygwin_core_osabi_sniffer.
---
 gdb/ChangeLog            |  5 +++++
 gdb/amd64-windows-tdep.c | 25 +++++++++++++++++++++++++
 2 files changed, 30 insertions(+)

-- 
2.27.0

Comments

Simon Marchi July 2, 2020, 11:59 p.m. | #1
> @@ -1276,6 +1278,24 @@ amd64_windows_osabi_sniffer (bfd *abfd)

>    return GDB_OSABI_WINDOWS;

>  }

>  

> +static enum gdb_osabi

> +amd64_cygwin_core_osabi_sniffer (bfd *abfd)

> +{

> +  const char *target_name = bfd_get_target (abfd);

> +

> +  /* Cygwin uses elf core dumps.  Do not claim all ELF executables,

> +     check whether there is a .reg section of proper size.  */

> +  if (strcmp (target_name, "elf64-x86-64") == 0)

> +    {

> +      asection *section = bfd_get_section_by_name (abfd, ".reg");

> +      if (section != nullptr

> +	  && bfd_section_size (section) == AMD64_WINDOWS_SIZEOF_GREGSET)

> +	return GDB_OSABI_CYGWIN;

> +    }

> +

> +  return GDB_OSABI_UNKNOWN;


The obvious question here is, what happens if we are loading the core for
another architecture, and it happens by bad luck that the .reg section is
of that size, even though it's not a Cygwin core.  Will this give a false
positive?

I presume that since this is copied on the i386, that discussion already
happened in the past for i386, and it was concluded that there was no better
way to identify a Cygwin core.  But I thought I'd ask just to be sure.

Simon
Jon Turney July 3, 2020, 1:30 p.m. | #2
On 03/07/2020 00:59, Simon Marchi wrote:
>> @@ -1276,6 +1278,24 @@ amd64_windows_osabi_sniffer (bfd *abfd)

>>     return GDB_OSABI_WINDOWS;

>>   }

>>   

>> +static enum gdb_osabi

>> +amd64_cygwin_core_osabi_sniffer (bfd *abfd)

>> +{

>> +  const char *target_name = bfd_get_target (abfd);

>> +

>> +  /* Cygwin uses elf core dumps.  Do not claim all ELF executables,

>> +     check whether there is a .reg section of proper size.  */

>> +  if (strcmp (target_name, "elf64-x86-64") == 0)

>> +    {

>> +      asection *section = bfd_get_section_by_name (abfd, ".reg");

>> +      if (section != nullptr

>> +	  && bfd_section_size (section) == AMD64_WINDOWS_SIZEOF_GREGSET)

>> +	return GDB_OSABI_CYGWIN;

>> +    }

>> +

>> +  return GDB_OSABI_UNKNOWN;

> 

> The obvious question here is, what happens if we are loading the core for

> another architecture, and it happens by bad luck that the .reg section is

> of that size, even though it's not a Cygwin core.  Will this give a false

> positive?


It would seem to.

> I presume that since this is copied on the i386, that discussion already

> happened in the past for i386, and it was concluded that there was no better

> way to identify a Cygwin core.  But I thought I'd ask just to be sure.


idk.  The x86 Cygwin core dump support was added in 2000 (see commit 
16e9c715dffb96efda481dc20cdb5bb6fbde0dff), when I was blissfully 
ignorant of all this nonsense :).

It certainly would be possible to improve this by checking if the ELF 
file contains a note of type NT_WIN32PSTATUS, but I'm not sure how we 
might do that here.
Simon Marchi July 3, 2020, 2:17 p.m. | #3
On 2020-07-03 9:30 a.m., Jon Turney wrote:
> It certainly would be possible to improve this by checking if the ELF file contains a note of type NT_WIN32PSTATUS, but I'm not sure how we might do that here.


You have access to the `bfd *`.  I'm not familiar with the BFD API, but
surely it can give you access to that?

Simon
Jon Turney July 6, 2020, 6:46 p.m. | #4
On 03/07/2020 15:17, Simon Marchi wrote:
> On 2020-07-03 9:30 a.m., Jon Turney wrote:

>> It certainly would be possible to improve this by checking if the ELF file contains a note of type NT_WIN32PSTATUS, but I'm not sure how we might do that here.

> 

> You have access to the `bfd *`.  I'm not familiar with the BFD API, but

> surely it can give you access to that?


"notes" don't appear to be part of the data model used by the BFD API 
(which I guess is why they are turned into pseudo-sections by the 
various functions called by elfcore_grok_note())

Patch

diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c
index 487dfd45fc7..e55d021b6c0 100644
--- a/gdb/amd64-windows-tdep.c
+++ b/gdb/amd64-windows-tdep.c
@@ -42,6 +42,8 @@  static int amd64_windows_dummy_call_integer_regs[] =
   AMD64_R9_REGNUM            /* %r9 */
 };
 
+#define AMD64_WINDOWS_SIZEOF_GREGSET 1232
+
 /* Return nonzero if an argument of type TYPE should be passed
    via one of the integer registers.  */
 
@@ -1276,6 +1278,24 @@  amd64_windows_osabi_sniffer (bfd *abfd)
   return GDB_OSABI_WINDOWS;
 }
 
+static enum gdb_osabi
+amd64_cygwin_core_osabi_sniffer (bfd *abfd)
+{
+  const char *target_name = bfd_get_target (abfd);
+
+  /* Cygwin uses elf core dumps.  Do not claim all ELF executables,
+     check whether there is a .reg section of proper size.  */
+  if (strcmp (target_name, "elf64-x86-64") == 0)
+    {
+      asection *section = bfd_get_section_by_name (abfd, ".reg");
+      if (section != nullptr
+	  && bfd_section_size (section) == AMD64_WINDOWS_SIZEOF_GREGSET)
+	return GDB_OSABI_CYGWIN;
+    }
+
+  return GDB_OSABI_UNKNOWN;
+}
+
 void _initialize_amd64_windows_tdep ();
 void
 _initialize_amd64_windows_tdep ()
@@ -1287,4 +1307,9 @@  _initialize_amd64_windows_tdep ()
 
   gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_coff_flavour,
 				  amd64_windows_osabi_sniffer);
+
+  /* Cygwin uses elf core dumps.  */
+  gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_elf_flavour,
+				  amd64_cygwin_core_osabi_sniffer);
+
 }