From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107368 invoked by alias); 26 Jan 2017 15:20:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 107358 invoked by uid 89); 26 Jan 2017 15:20:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=detecting, H*i:sk:wwok7f5, H*f:sk:wwok7f5, H*MI:sk:wwok7f5 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Jan 2017 15:20:47 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D6D6F624D3; Thu, 26 Jan 2017 15:20:47 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0QFKhem031708; Thu, 26 Jan 2017 10:20:47 -0500 Subject: Re: [PATCH] Fix crash when loading a core with unexpected register section size To: Antoine Tremblay References: <1485436646-12223-1-git-send-email-antoine.tremblay@ericsson.com> <3c0fb039-513d-9c8a-5851-e13a32d3d3ea@redhat.com> <3ac9874b-d4c9-8cb2-c4ab-81d20d41689d@redhat.com> <6c8d340f-156d-f619-bf81-1c1780759a17@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <379390ed-98c6-fb7b-b217-b768e435bf5e@redhat.com> Date: Thu, 26 Jan 2017 15:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00581.txt.bz2 On 01/26/2017 02:59 PM, Antoine Tremblay wrote: > >>> Ho yes, see v2, I added "For example arch-arm." Like you suggested. >> >> Eh, "arch-" in "arch-foo" was just meant to show I was talking >> about an arch. I didn't mean for you to keep the "arch-" part. :-) > > hehe I figured but wasn't sure. I'll just say arm. The right name is uppercase "ARM". ;-) >> So basically, we could have a testcase that dumps a file, and then >> loads with back with no executable loaded? Do we really not >> have such a testcase yet? >> > > Not exactly if it was that simple it would have been catched by > gdb.base/corefile.exp > > The problem is that this triggers only if the core file register section > is larger than expected. And if you just create a core and read it the > register section is ok. > > However crafting a core with this problem is non-trivial at least to my > current knowledge. This is all information that would have been very handy to have in the submission upfront. Please put it in the commit log. OK with that change. One piece of info missing is why didn't GDB figure out this is a Linux core anyway, assuming it's a Linux core dump. I think the answer is that there's no ".note.ABI-tag"/NT_GNU_ABI_TAG section/note in core dumps. I think we could teach generic_elf_osabi_sniff_abi_tag_sections about detecting presence of ".note.linuxcore" sections: $ objdump -h ./testsuite/core.7452 [...] 3 .note.linuxcore.siginfo/7452 00000080 0000000000000000 0000000000000000 0000075c 2**2 [...] And then we'd end up with a gdbarch that has arm_linux_iterate_over_regset_sections installed, and thus no crash. But we shouldn't crash if NT_SIGINFO notes are missing, so the patch is OK as is. Thanks, Pedro Alves