Message ID | Y3QKUwDn748CbDIs@squeak.grove.modra.org |
---|---|
State | Repeat Merge |
Headers |
Return-Path: <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2957441wru; Tue, 15 Nov 2022 13:53:35 -0800 (PST) X-Google-Smtp-Source: AA0mqf6ALbwhaA32VlmYHOM8zWx1+H744eAdq+7mIgzmeHQaWgUVxqB44/GYORBLATonefSkw8DG X-Received: by 2002:a17:906:b45:b0:78d:b65a:aabe with SMTP id v5-20020a1709060b4500b0078db65aaabemr15775860ejg.5.1668549215803; Tue, 15 Nov 2022 13:53:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668549215; cv=none; d=google.com; s=arc-20160816; b=ryOJLvadqODgWrdxWz1bFbdOHzqSzdW3pk7BIXBHXx+o44ZoPtk7QyXu5cQE2QGjfU eGhXHv8FWj7DbetPc0SnRYsbLEvrcj3UsT2K1eh3bG2MQpErQiHT60PmsllGh2vPxcbI f4lajnqWg6AdS3sg/SfX9dlxJN7QBI1Tej/DmVjFfEKuFpaDMTegKBj+zXW/94rovG0j xeM26mnOvpskzHg96D5SQq1+4EG9x8LbrowloW3vFHazjihi01N2/o04JErR1mGsLTWn P9IXhWqYSykswZJfIgUbsfFn8bw58y3yofcyfkezDgrEFeQw4NG1BUVt08K6xw01f/xe HvPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=Uo2AH0ytPWjBViMnw4JumqZdycq4fSoqNhsvpjIhLYM=; b=ejciRPq8c6So8PXlCX0VYYfeZk3mxHfGbjoSS0NNxVVY3pXWyClKFeFn0K5rqmFRMY GbJvURaFtMhfSQeyqsyAJUA5GY+qXnhQtzzOZhRADlzv96R9EFc8XFkB5i/Zsu72SC4k HYp6x/azwW0LEvSjp4ilAvid9IHFl+QnFR0FkG0sJXoaER90BY/Y0IQFBq7HO491Y86+ 5ngw4B7vc/TIRur+rtKiUkjOKWQRD1oF2NQpZXnEumHWaXdIOzR/hpFVY7hocN0Ujful IGeHUbW40d3RD2xkyQdJpIKJfddgK4JODLWi8JlXN3x5+Db0310jY2MbThJjg8x60SSM kD0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=lws7+Vi3; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id y8-20020a056402270800b004675cf238cbsi10770470edd.322.2022.11.15.13.53.35 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 13:53:35 -0800 (PST) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=lws7+Vi3; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 93F36393BC3A for <ouuuleilei@gmail.com>; Tue, 15 Nov 2022 21:53:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93F36393BC3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668549214; bh=Uo2AH0ytPWjBViMnw4JumqZdycq4fSoqNhsvpjIhLYM=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=lws7+Vi3e2Tjo+A7BSMfGY+uovLwRj6aVrXycZORsid71vzYsz0gmGq1mzKqCAfMV Jmbvv30JqLPVs/zuxn1+vmyMtO56yZvk/CH+v1V5TZZC3hiy0GVSpZRRsdileT95gh Sw0te6jnzvrgqHihCaSG4EFKv8k8itFenvBowoOw= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 08159393BA76 for <binutils@sourceware.org>; Tue, 15 Nov 2022 21:53:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08159393BA76 Received: by mail-pj1-x102d.google.com with SMTP id c15-20020a17090a1d0f00b0021365864446so327669pjd.4 for <binutils@sourceware.org>; Tue, 15 Nov 2022 13:53:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uo2AH0ytPWjBViMnw4JumqZdycq4fSoqNhsvpjIhLYM=; b=Y6dTABtZMELJeSDP/y5hbEDiJoMxKSthrlsvh/qkrHStIyDRe0rSlKhEQWvVxFNcSB Be7J0V4rdA2QWW6kjmITE94ddpNwUGKF2byT351eRcoDfWrD0MtumQKuI8rnyxErJRr3 4oandAFvMc55xy3hFK+8ZAWTXweAHam4gq74tMWooaod7fxexJrrB9TPFwIiJUVSJR+W m2JSASAERxCc5x76p2Fde7FVOSTCyujXCQvePhzlh6fgpXfAtuLlDfOEDyC4J9OYYAUk Y0yFOZImT30A659nwWT4NCSu8pOzvgCus8oZFVUD5LktOw5o1mTL1N08+zlwcsMPUu+Y jzQg== X-Gm-Message-State: ANoB5pnYgz0uyDpwqlzd7fhm03ULCIGRUNAT/R3n/q0bld8L//anf528 zz7GlFFeE51M5VTPV5i1JC8= X-Received: by 2002:a17:902:f60d:b0:186:6019:d49d with SMTP id n13-20020a170902f60d00b001866019d49dmr5853791plg.140.1668549206031; Tue, 15 Nov 2022 13:53:26 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:68c9:a23e:cf1b:b0be]) by smtp.gmail.com with ESMTPSA id u16-20020a170902e5d000b00186fb8f931asm10501373plf.206.2022.11.15.13.53.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 13:53:25 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 1B43B1142DD4; Wed, 16 Nov 2022 08:23:23 +1030 (ACDT) Date: Wed, 16 Nov 2022 08:23:23 +1030 To: Zac Walker <zac.walker@linaro.org> Cc: Nick Clifton <nickc@redhat.com>, binutils@sourceware.org Subject: aarch64-pe can't fill 16 bytes in section .text Message-ID: <Y3QKUwDn748CbDIs@squeak.grove.modra.org> References: <f659dfbb-b84b-af86-bd8c-d177900af779@linaro.org> <1fc98550-06e7-284e-3f1c-dda991bdd0e5@redhat.com> <584ecd9c-7876-8e2f-4610-8b51cab366b8@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <584ecd9c-7876-8e2f-4610-8b51cab366b8@linaro.org> X-Spam-Status: No, score=-3035.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> From: Alan Modra via Binutils <binutils@sourceware.org> Reply-To: Alan Modra <amodra@gmail.com> Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749600662963604808?= X-GMAIL-MSGID: =?utf-8?q?1749600662963604808?= |
Series |
aarch64-pe can't fill 16 bytes in section .text
|
|
Checks
Context | Check | Description |
---|---|---|
snail/binutils-gdb-check | warning | Git am fail log |
Commit Message
Alan Modra
Nov. 15, 2022, 9:53 p.m. UTC
I'm going to fix the underlying coff_frob_section problem too. Without commit b66e671854, this: .p2align 4 nop .p2align 3 nop results in an error when coff_frob_section attempts to pad out the section to a 16-byte boundary. Due to miscalculating the pad pattern repeat count, write.c:write_contents attempts to shove 16 bytes of padding into the remaining 4 bytes of the .text section. * config/obj-coff.c (coff_frob_section): Correct fill count. Don't pad after errors.
Comments
Thanks Alan, Do you think my SUB_SEGMENT_ALIGN patch is still needed. I didn't merge it yet because I wanted to do more testing with your fix. Zac --- gas/config/tc-aarch64.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gas/config/tc-aarch64.h b/gas/config/tc-aarch64.h index 2d514ff610..0ea73021f2 100644 --- a/gas/config/tc-aarch64.h +++ b/gas/config/tc-aarch64.h @@ -191,7 +191,10 @@ struct aarch64_frag_type goto LABEL; \ } +/* COFF sub section alignment calculated using the write.c implementation. */ +#ifndef OBJ_COFF #define SUB_SEGMENT_ALIGN(SEG, FRCHAIN) 0 +#endif #define DWARF2_LINE_MIN_INSN_LENGTH 4
On Wed, Nov 16, 2022 at 06:03:56PM +0100, Zac Walker wrote: > Thanks Alan, > > Do you think my SUB_SEGMENT_ALIGN patch is still needed. I didn't merge it yet because I wanted to do more testing with your fix. Huh, I thought it had already gone in, but it was just in my local tree. Your patch isn't needed with my fix to obj-coff.c, but it wouldn't be a bad idea to apply it anyway. We have a few too many places doing section padding. It would be nice to get rid of the alignment code in coff_frob_section.
Patch merged just now. (Was a holiday here yesterday) I am still investigating another alignment problem so might be another follow up patch. This code from OpenBLAS: data_ar: .word 0x3e44fae6 data_ai: .word 0x3d320fa2 start: ldr s20, data_ar ldr s21, data_ai Produces: zscal-min.s:2: Warning: value 0x3e44fae6 truncated to 0xfae6 zscal-min.s:4: Warning: value 0x3d320fa2 truncated to 0xfa2 zscal-min.s:7: Error: pc-relative load offset not word aligned Works ok with clang. I am not sure if .word data should be aligned by default in gas or this is just a difference in behaviour. Thanks, Zac -----Original Message----- From: Alan Modra <amodra@gmail.com> Sent: 17 November 2022 04:02 To: Zac Walker <zac.walker@linaro.org> Cc: Nick Clifton <nickc@redhat.com>; binutils@sourceware.org Subject: Re: aarch64-pe can't fill 16 bytes in section .text On Wed, Nov 16, 2022 at 06:03:56PM +0100, Zac Walker wrote: > Thanks Alan, > > Do you think my SUB_SEGMENT_ALIGN patch is still needed. I didn't merge it yet because I wanted to do more testing with your fix. Huh, I thought it had already gone in, but it was just in my local tree. Your patch isn't needed with my fix to obj-coff.c, but it wouldn't be a bad idea to apply it anyway. We have a few too many places doing section padding. It would be nice to get rid of the alignment code in coff_frob_section. -- Alan Modra Australia Development Lab, IBM
On 18.11.2022 09:52, Zac Walker via Binutils wrote: > Patch merged just now. (Was a holiday here yesterday) > > I am still investigating another alignment problem so might be another follow up patch. This code from OpenBLAS: > > data_ar: > .word 0x3e44fae6 > data_ai: > .word 0x3d320fa2 > start: > ldr s20, data_ar > ldr s21, data_ai > > Produces: > > zscal-min.s:2: Warning: value 0x3e44fae6 truncated to 0xfae6 > zscal-min.s:4: Warning: value 0x3d320fa2 truncated to 0xfa2 > zscal-min.s:7: Error: pc-relative load offset not word aligned > > Works ok with clang. I am not sure if .word data should be aligned by default in gas or this is just a difference in behaviour. .word is overridden by tc-aarch64.c only for ELF. So in your COFF (aiui) case .word emits just two bytes instead of the expected four. Hence also the warnings, not just the error. Jan
Thanks for the help Jan. Adding a similar override to "tc-arm.c" fixes it: #ifdef OBJ_ELF ... #else { "word", cons, 4}, #endif I will do some testing on other pseudo types in case I am missing more. Zac -----Original Message----- From: Jan Beulich <jbeulich@suse.com> Sent: 18 November 2022 10:09 To: zac.walker@linaro.org Cc: 'Nick Clifton' <nickc@redhat.com>; binutils@sourceware.org; 'Alan Modra' <amodra@gmail.com> Subject: Re: aarch64-pe can't fill 16 bytes in section .text On 18.11.2022 09:52, Zac Walker via Binutils wrote: > Patch merged just now. (Was a holiday here yesterday) > > I am still investigating another alignment problem so might be another follow up patch. This code from OpenBLAS: > > data_ar: > .word 0x3e44fae6 > data_ai: > .word 0x3d320fa2 > start: > ldr s20, data_ar > ldr s21, data_ai > > Produces: > > zscal-min.s:2: Warning: value 0x3e44fae6 truncated to 0xfae6 > zscal-min.s:4: Warning: value 0x3d320fa2 truncated to 0xfa2 > zscal-min.s:7: Error: pc-relative load offset not word aligned > > Works ok with clang. I am not sure if .word data should be aligned by default in gas or this is just a difference in behaviour. .word is overridden by tc-aarch64.c only for ELF. So in your COFF (aiui) case .word emits just two bytes instead of the expected four. Hence also the warnings, not just the error. Jan
diff --git a/gas/config/obj-coff.c b/gas/config/obj-coff.c index 98c39e43907..9be697fb62e 100644 --- a/gas/config/obj-coff.c +++ b/gas/config/obj-coff.c @@ -1725,7 +1725,8 @@ coff_frob_section (segT sec) bfd_vma align_power = (bfd_vma) sec->alignment_power + OCTETS_PER_BYTE_POWER; bfd_vma mask = ((bfd_vma) 1 << align_power) - 1; - if (size & mask) + if (!do_not_pad_sections_to_alignment + && (size & mask) != 0) { bfd_vma new_size; fragS *last; @@ -1740,7 +1741,10 @@ coff_frob_section (segT sec) while (fragp->fr_next != last) fragp = fragp->fr_next; last->fr_address = size; - fragp->fr_offset += new_size - size; + if ((new_size - size) % fragp->fr_var == 0) + fragp->fr_offset += (new_size - size) / fragp->fr_var; + else + abort (); } #endif