From patchwork Thu Jun 8 14:07:48 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Richard Earnshaw \(lists\)" X-Patchwork-Id: 103396 Delivered-To: patch@linaro.org Received: by 10.140.91.77 with SMTP id y71csp2457992qgd; Thu, 8 Jun 2017 07:08:12 -0700 (PDT) X-Received: by 10.98.204.150 with SMTP id j22mr36926918pfk.236.1496930892383; Thu, 08 Jun 2017 07:08:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1496930892; cv=none; d=google.com; s=arc-20160816; b=xSTl4k8N+JuoXwCup7rxGUa6gtOduAgoGWqi7F32yEuvdmwdlYgX/86FHDho2huLWK O56tzP+n4VnNgKg9vxsNAX5zVv1b4Fgqel+Cs79iqe6hpKzm15b9NNq7RUsAGj3lkOUT g+qKa0To1QrcJ0hKV+UFRdb4OBFCE2TnwIvdCMCgo6zXMC7Hm3jWUafxzp3Me6mMfjhw gOj8rUhfEj3yftdmW2dWpJHzbnINuimLlJPaZvS2wVhhkujdHxddfvDTNuluUcLHB17W WwF8/WArrJdHtU9d3tguLXBWNNWvZrJqvUyyCU3ikVn0onYUHHT4z43tUGI3aTGR1+Cj I69g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:date:message-id:subject:from:to :delivered-to:sender:list-help:list-post:list-archive:list-subscribe :list-unsubscribe:list-id:precedence:mailing-list:dkim-signature :domainkey-signature:arc-authentication-results; bh=k3fckwJcBsPKUO/7CGXYclc8kQ4tJhAtNVy5my7QsqU=; b=TAcWJxx2hjSV5JjQvqMGd+9BXGFe/QWqdfTh3g00hOlTw5+xRIuryUG/FkKWdiUby1 +OLcpJQCP8CD409vjzEOcxJ26cqMm7bzYfG+WVbbd/tePEibjHYqdS9kMh1MEpspZa1V 8ND7EsmHWKvrwG4VRg6W6mZOmn7aNF0fSKA6+zTHSkanPcSeU0sjGvE0HoURRibSi6m1 kpvoIlztPyEy4U0apXg2XAFcEOIQJelJUotJymAqAEy+Jk+g9YFD0a/GvZiqp2MC9hYX o8JHoZ0chVknxkqo8uY/vFENm0JnKVCDylmeOvtMP9U9cGJwFLx9YSBjUa6hAOkGeCyA yMnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org; spf=pass (google.com: domain of binutils-return-97146-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=binutils-return-97146-patch=linaro.org@sourceware.org Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id p1si233649pfg.7.2017.06.08.07.08.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 07:08:12 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-return-97146-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org; spf=pass (google.com: domain of binutils-return-97146-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=binutils-return-97146-patch=linaro.org@sourceware.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type; q=dns; s=default; b=hzpzc48fn8g+p/tWaHN3UOWstRwIi CeFe6e4m7DseVNDM4quOKV2ELs5wwt7Eb8hLzwGvgLo2GDkoPGXCGvtFAKgt+Tks Snc0cslNjBZvX1WUvD7XpVJp794qf2/RF9paSjO3w07s+cj0dNaCgylmDG6YnJeP DB5z/X+L7ldeq4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type; s=default; bh=HsrBJrvmuFGtZuUNfp5D3eVv0tc=; b=PdY CrHyV4l+uizMTaKuIc6qts3i59d09cyXcLDUdTQ9/T9b0cM2p1eYzZPpjA0x4d9S h2+x9AHl5AoMLlNs7xuvDXjrCE8oZaNcAzb4GQSjU3D3WhpBwspsbWLl0UmSe1zz yaYTDfxR9YiJQ8n+WQPtc/mdil18H6pLmPW0AH+g= Received: (qmail 118522 invoked by alias); 8 Jun 2017 14:07:49 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Delivered-To: mailing list binutils@sourceware.org Received: (qmail 117584 invoked by uid 89); 8 Jun 2017 14:07:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=suspicious, clarifying, our X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Jun 2017 14:07:47 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8361F1596; Thu, 8 Jun 2017 07:07:50 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 092963F3E1; Thu, 8 Jun 2017 07:07:49 -0700 (PDT) To: binutils@sourceware.org From: "Richard Earnshaw (lists)" Subject: [bfd][arm] Don't assert on suspicious build attributes in input file Message-ID: <99e452dd-eba7-ebc5-74f2-c17b71872867@arm.com> Date: Thu, 8 Jun 2017 15:07:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 It's generally a bad idea to use assertions to validate our idea of what an input file looks like. We need to be as liberal as possible in what we accept with respect to standards and conservative with what we produce. Currently, if gcc is used to produce an assembler file which contains only data, but the FPU is set to fpv4-sp-d16 and mfloat-abi=hard, then the following attributes will be set in the output: .cpu arm7tdmi .eabi_attribute 27, 1 @ Tag_ABI_HardFP_use .eabi_attribute 28, 1 @ Tag_ABI_VFP_args .eabi_attribute 20, 1 @ Tag_ABI_FP_denormal .eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions .eabi_attribute 23, 3 @ Tag_ABI_FP_number_model .eabi_attribute 24, 1 @ Tag_ABI_align8_needed .eabi_attribute 25, 1 @ Tag_ABI_align8_preserved .eabi_attribute 26, 2 @ Tag_ABI_enum_size .eabi_attribute 30, 6 @ Tag_ABI_optimization_goals .eabi_attribute 34, 0 @ Tag_CPU_unaligned_access .eabi_attribute 18, 4 @ Tag_ABI_PCS_wchar_t There is then no .fpu directive to cause Tag_FP_arch to be set, because there are no functions containing code in the object file. If this object file is assembled by hand, but without -mfpu on the invocation of the assembler, then the build attributes produced will trigger an assertion during linking. Thinking about the build attributes, the combination of a single-precision only implementation of no floating-point architecture is still no floating-point architecture. Hence the assertion on the input BFD in the linker makes no real sense. We should, however, be more conservative in what we generate, so I've left the assertion on the output bfd in place; I don't think we can trigger it with this change since we never merge the problematic tags from a perversely generated input file. * elf32-arm.c (elf32_arm_merge_eabi_attributes): Remove assertion that the input bfd has Tag_FP_ARCH non-zero if Tag_ABI_HardFP_use is non-zero. Add clarifying comments. I'll commit this shortly. R. diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c index 0a78595..85ecca5 100644 --- a/bfd/elf32-arm.c +++ b/bfd/elf32-arm.c @@ -13816,6 +13816,9 @@ elf32_arm_merge_eabi_attributes (bfd *ibfd, struct bfd_link_info *info) follow the requirement of the input. */ if (out_attr[i].i == 0) { + /* This assert is still reasonable, we shouldn't + produce the suspicious build attribute + combination (See below for in_attr). */ BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0); out_attr[i].i = in_attr[i].i; out_attr[Tag_ABI_HardFP_use].i @@ -13826,7 +13829,13 @@ elf32_arm_merge_eabi_attributes (bfd *ibfd, struct bfd_link_info *info) nothing. */ else if (in_attr[i].i == 0) { - BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0); + /* We used to assert that Tag_ABI_HardFP_use was + zero here, but we should never assert when + consuming an object file that has suspicious + build attributes. The single precision variant + of 'no FP architecture' is still 'no FP + architecture', so we just ignore the tag in this + case. */ break; }