From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-046.btinternet.com (mailomta12-sa.btinternet.com [213.120.69.18]) by sourceware.org (Postfix) with ESMTPS id 97F903861916 for ; Fri, 3 Jul 2020 13:30:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 97F903861916 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-046.btinternet.com with ESMTP id <20200703133031.DUNA4114.sa-prd-fep-046.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net>; Fri, 3 Jul 2020 14:30:31 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-Originating-IP: [31.51.206.31] X-OWM-Source-IP: 31.51.206.31 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedrtdeigdeiiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeeguefhkedvfeeigefhhedtjeehieegtdehhffhheffgfehheegtdffleejteeuueenucfkphepfedurdehuddrvddtiedrfedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurdduuddungdpihhnvghtpeefuddrhedurddvtdeirdefuddpmhgrihhlfhhrohhmpeeojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhequceuqfffjgepkeeukffvoffkoffgpdhrtghpthhtohepoehguggsqdhprghttghhvghssehsohhurhgtvgifrghrvgdrohhrgheqpdhrtghpthhtohepoehsihhmrghrkhesshhimhgrrhhkrdgtrgeq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (31.51.206.31) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9AA6E04FD89DA; Fri, 3 Jul 2020 14:30:31 +0100 Subject: Re: [PATCH 4/7] Add sniffer for Cygwin x86_64 core dumps To: gdb-patches@sourceware.org References: <20200701213225.14144-1-jon.turney@dronecode.org.uk> <20200701213225.14144-5-jon.turney@dronecode.org.uk> From: Jon Turney Cc: Simon Marchi Message-ID: <3b447063-417f-b0f2-85bc-2c18f92d08cf@dronecode.org.uk> Date: Fri, 3 Jul 2020 14:30:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no 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: Fri, 03 Jul 2020 13:30:33 -0000 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.