From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C04943858D34 for ; Thu, 2 Jul 2020 23:59:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C04943858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 64C991ED02; Thu, 2 Jul 2020 19:59:44 -0400 (EDT) Subject: Re: [PATCH 4/7] Add sniffer for Cygwin x86_64 core dumps To: Jon Turney , gdb-patches@sourceware.org References: <20200701213225.14144-1-jon.turney@dronecode.org.uk> <20200701213225.14144-5-jon.turney@dronecode.org.uk> From: Simon Marchi Message-ID: Date: Thu, 2 Jul 2020 19:59:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200701213225.14144-5-jon.turney@dronecode.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, 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: Thu, 02 Jul 2020 23:59:45 -0000 > @@ -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