From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 905D7385BF92 for ; Wed, 1 Apr 2020 21:37:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 905D7385BF92 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-194-mvQmgFINPea9LDnPJYCf6Q-1; Wed, 01 Apr 2020 17:36:55 -0400 X-MC-Unique: mvQmgFINPea9LDnPJYCf6Q-1 Received: by mail-wr1-f72.google.com with SMTP id i18so461219wrx.17 for ; Wed, 01 Apr 2020 14:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SjFI9mJ7+EwaVWxR1hanCGv+jfqYkgeg8bATnZwcI+U=; b=rjhWiutLOG6GPIOCw+Kv353aruQi5PISsbjHD714IvZFHJo6oAJNzNEdknKVd6iPFA ftE9cK2oPFbp0f33dSpvFm+Jb+zkKl0e4FQ6DMySFlcAiH20ZFb7wKjrbQ4gdGgMheef OcjRi5WnlOWMyJBhwLYEB2n0U8/jlK1Nib4Im+e/N2HHEfORzdI+suR3/8b0kHw6qJVj VOqiCySWfC++iFIHE893QN/pMTWUDZw+KtKkC1O3VlPYRNRAYXAKlgDbqMaSPjCHaDqO 4eqclXSR2fosEE2WHgKuWXVejdncdD1m8zeSLiUroq1AyyNd9vRRKGo/GkJavPyGOH2L n8mg== X-Gm-Message-State: ANhLgQ18VVaNpNug5eqXP+1tVlMFunO/Zzp2Zp62lWwqiuDAL2WPFxHA ic5bxREepWZwUFPEHakO5Fh6qJhIhv1rlGwNDZDPOb6yWhFNt/JWXAGiGxzNXqIa1ftgQsR0qG7 H00hkU9SCadTcfh7Y2xLSNQ== X-Received: by 2002:a5d:60cc:: with SMTP id x12mr30089360wrt.149.1585777014586; Wed, 01 Apr 2020 14:36:54 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtRzg8w6MpzyGbQ0DobcPxDVT0DN8jBe88BfjFK/NvtywEWXdnCRufsn8o0SbsdBwo3sZKcWQ== X-Received: by 2002:a5d:60cc:: with SMTP id x12mr30089330wrt.149.1585777014261; Wed, 01 Apr 2020 14:36:54 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 138sm4296466wmb.21.2020.04.01.14.36.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 14:36:53 -0700 (PDT) Subject: Re: [PATCH 6/7] gdb: select "Cygwin" OS ABI for Cygwin binaries To: Simon Marchi , gdb-patches@sourceware.org References: <20200316170845.184386-1-simon.marchi@polymtl.ca> <20200316170845.184386-7-simon.marchi@polymtl.ca> Cc: Jon Turney , Simon Marchi From: Pedro Alves Message-ID: <0b76517a-f6dd-0aa8-17fb-ce5a9accbf42@redhat.com> Date: Wed, 1 Apr 2020 22:36:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200316170845.184386-7-simon.marchi@polymtl.ca> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-19.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 21:37:04 -0000 On 3/16/20 5:08 PM, Simon Marchi via Gdb-patches wrote: > From: Simon Marchi > > Before this patch, the "Windows" OS ABI is selected for all Windows > executables, including Cygwin ones. This patch makes GDB differentiate > Cygwin binaries from non-Cygwin ones, and selects the "Cygwin" OS ABI > for the Cygwin ones. > > To check whether a Windows PE executable is a Cygwin one, we check the > library list in the .idata section, see if it contains "cygwin1.dll". > > I had to add code to parse the .idata section, because BFD doesn't seem > to expose this information. BFD does parse this information, but only > to print it in textual form (function pe_print_idata): > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/peXXigen.c;h=e42d646552a0ca1e856e082256cd3d943b54ddf0;hb=HEAD#l1261 > > Here's the relevant portion of the PE format documentation: > > https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section > > This page was also useful: > > https://blog.kowalczyk.info/articles/pefileformat.html#9ccef823-67e7-4372-9172-045d7b1fb006 > > With this patch applied, this is what I get: > > (gdb) file some_mingw_x86_64_binary.exe > Reading symbols from some_mingw_x86_64_binary.exe... > (gdb) show osabi > The current OS ABI is "auto" (currently "Windows"). > The default OS ABI is "GNU/Linux". > > (gdb) file some_mingw_i386_binary.exe > Reading symbols from some_mingw_i386_binary.exe... > (gdb) show osabi > The current OS ABI is "auto" (currently "Windows"). > The default OS ABI is "GNU/Linux". > > (gdb) file some_cygwin_x86_64_binary.exe > Reading symbols from some_cygwin_x86_64_binary.exe... > (gdb) show osabi > The current OS ABI is "auto" (currently "Cygwin"). > The default OS ABI is "GNU/Linux". > > gdb/ChangeLog: > > * windows-tdep.h (is_linked_with_cygwin_dll): New declaration. > * windows-tdep.c (CYGWIN_DLL_NAME): New. > (pe_import_directory_entry): New struct type. > (is_linked_with_cygwin_dll): New function. > * amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Select > GDB_OSABI_CYGWIN if the BFD is linked with the Cygwin DLL. > * i386-windows-tdep.c (i386_windows_osabi_sniffer): Likewise. > --- > gdb/amd64-windows-tdep.c | 9 ++-- > gdb/i386-windows-tdep.c | 9 ++-- > gdb/windows-tdep.c | 101 +++++++++++++++++++++++++++++++++++++++ > gdb/windows-tdep.h | 6 +++ > 4 files changed, 119 insertions(+), 6 deletions(-) > > diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c > index 88ff794abcb6..e0346f8628fe 100644 > --- a/gdb/amd64-windows-tdep.c > +++ b/gdb/amd64-windows-tdep.c > @@ -1249,10 +1249,13 @@ amd64_windows_osabi_sniffer (bfd *abfd) > { > const char *target_name = bfd_get_target (abfd); > > - if (strcmp (target_name, "pei-x86-64") == 0) > - return GDB_OSABI_WINDOWS; > + if (!streq (target_name, "pei-x86-64")) > + return GDB_OSABI_UNKNOWN; > > - return GDB_OSABI_UNKNOWN; > + if (is_linked_with_cygwin_dll (abfd)) > + return GDB_OSABI_CYGWIN; > + > + return GDB_OSABI_WINDOWS; > } > > void _initialize_amd64_windows_tdep (); > diff --git a/gdb/i386-windows-tdep.c b/gdb/i386-windows-tdep.c > index a71ceda781f8..bd6107b02f1f 100644 > --- a/gdb/i386-windows-tdep.c > +++ b/gdb/i386-windows-tdep.c > @@ -232,10 +232,13 @@ i386_windows_osabi_sniffer (bfd *abfd) > { > const char *target_name = bfd_get_target (abfd); > > - if (strcmp (target_name, "pei-i386") == 0) > - return GDB_OSABI_WINDOWS; > + if (!streq (target_name, "pei-i386")) > + return GDB_OSABI_UNKNOWN; > > - return GDB_OSABI_UNKNOWN; > + if (is_linked_with_cygwin_dll (abfd)) > + return GDB_OSABI_CYGWIN; > + > + return GDB_OSABI_WINDOWS; > } > > static enum gdb_osabi > diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c > index e02b1ceed387..32e551bcb175 100644 > --- a/gdb/windows-tdep.c > +++ b/gdb/windows-tdep.c > @@ -38,6 +38,8 @@ > #include "libcoff.h" > #include "solist.h" > > +#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 > @@ -898,6 +900,105 @@ static const struct internalvar_funcs tlb_funcs = > NULL > }; > > +/* Layout of an element of a PE's Import Directory Table. Based on: > + > + https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-directory-table > + */ > + > +struct pe_import_directory_entry > +{ > + uint32_t import_lookup_table_rva; > + uint32_t timestamp; > + uint32_t forwarder_chain; > + uint32_t name_rva; > + uint32_t import_address_table_rva; > +}; > + > +gdb_static_assert (sizeof (pe_import_directory_entry) == 20); > + > +/* Return true if the Portable Executable behind ABFD uses the Cygwin dll > + (cygwin1.dll). */ > +/* See windows-tdep.h. */ > + > +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. > + > + /* 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. > + > + /* Is it the end of list marker? */ > + if (memcmp (dir_entry, &null_dir_entry, > + sizeof (pe_import_directory_entry)) == 0) > + break; > + > + bfd_vma name_addr = dir_entry->name_rva; > + > + /* If the name's virtual address is smaller than the section's virtual > + address, there's a problem. */ > + if (name_addr < idata_addr > + || name_addr >= (idata_addr + idata_size)) > + { > + warning (_("\ > +Failed to parse .idata section: name's virtual address (0x%" BFD_VMA_FMT "x) \ > +is outside .idata section's range [0x%" BFD_VMA_FMT "x, 0x%" BFD_VMA_FMT "x[."), > + name_addr, idata_addr, idata_addr + idata_size); > + break; > + } > + > + const gdb_byte *name = &idata_contents[name_addr - idata_addr]; > + > + /* Make sure we don't overshoot the end of the section with the streq. */ > + if (name + sizeof(CYGWIN_DLL_NAME) > end) Missing space before parens. Thanks, Pedro Alves