From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by sourceware.org (Postfix) with ESMTPS id 543E73858C56 for ; Sat, 23 Apr 2022 21:30:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 543E73858C56 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-f169.google.com with SMTP id c23so18601536plo.0 for ; Sat, 23 Apr 2022 14:30:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4RBM7CxYCa9SJTG1t2+uNZu++S66ql3UNTK8UZvSFdU=; b=fVdp+4xCY7nlBBJFDikcPoXMnGyPx3VpMM0bfc8YbXlfBENqY/plkEb2Avq209HSJl O9rPL5gro7UQ1LFnD7/xz3H8gT8p70tGfsTXjUnE2xAdePwmg4J5TOHoqydTYXe56d5J Wx0uIEyDipdoCGD5szCXE7yVnSr4bpFGaKb1Jk5lMeGqtY04nASS1uk7CRiRNEI2ibpw rd5GYF/IGQ+kAvP1ZRAZh312PdHM4jT7yokki5W6IyEbkj8y4SCMGRUUbnjU6D9+TV1b Cd1aNJXWYCPGSvM+Yn0neq3TRQKyj+FgmoUbNErOrk2JvylPnjEJvL6ob7HTIlt9mx1b QVYA== X-Gm-Message-State: AOAM533h04LZQpXYZX2veORH6lH5sfw9Yzro1cpXUQTADbuUyo69m596 636YNBgPlrAJmbhUTdOnFa+05NCruEw= X-Google-Smtp-Source: ABdhPJyYhgaSolcay/NWVmTnoH+4gN1sNgYemoj2OZTo11d2FqnNRvmVAZ+w0lrpEsFsAhInttiZkA== X-Received: by 2002:a17:903:4093:b0:15c:e5eb:9545 with SMTP id z19-20020a170903409300b0015ce5eb9545mr4323522plc.62.1650749418216; Sat, 23 Apr 2022 14:30:18 -0700 (PDT) Received: from localhost ([2601:647:6300:b760:2799:dcd2:d943:7605]) by smtp.gmail.com with ESMTPSA id lp5-20020a17090b4a8500b001cb978f906esm10925065pjb.0.2022.04.23.14.30.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Apr 2022 14:30:17 -0700 (PDT) Date: Sat, 23 Apr 2022 14:30:16 -0700 From: Fangrui Song To: Eric Botcazou Cc: binutils@sourceware.org Subject: Re: [PATCH] Orphan sections and NOLOAD output section Message-ID: <20220423213016.zorvmjv5cspqbkry@gmail.com> References: <2111887.irdbgypaU6@fomalhaut> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <2111887.irdbgypaU6@fomalhaut> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2022 21:30:21 -0000 On 2022-04-21, Eric Botcazou via Binutils wrote: >Hi, > >we recently got a report about a counter-intuitive behavior of the GNU linker >for orphan sections matched by a NOLOAD output section, which turned out to be >an exact duplicate of: > https://stackoverflow.com/questions/48764136/gcc-noload-directive-cause-wrong-memory-mapping > >What happens is that the effect of the command: > > .foo (NOLOAD) : {} > >is not equivalent to that of: > > .foo (NOLOAD) : { *(.foo) } > >when there is more than 1 object file containing a .foo section: the former >will output two .foo sections, the first with PROGBITS and the second with >NOBITS, where the latter will output only one with NOBITS. > >I think that the commands are essentially equivalent so the linker ought to yield >the same outcome, namely the single output section with NOBITS. > >Tested on x86-64/Linux, OK for the mainline? > > >2022-04-21 Eric Botcazou > >ld/ > * ldelf.c (ldelf_place_orphan): Match only by name for a NOLOAD > output section present in the script. > * testsuite/ld-elf/orphan-13.d: New file. > * testsuite/ld-elf/orphan-13.ld: Likewise. > * testsuite/ld-elf/orphan-13a.s: Likewise. > * testsuite/ld-elf/orphan-13b.s: Likewise. > * testsuite/ld-elf/orphan-13c.s: Likewise. > >-- >Eric Botcazou For other folks' convenience, the patch effect is changing % ld.bfd orphan-13[abc].o -T orphan-13.ld && readelf -S a.out | grep foo [ 1] .foo PROGBITS 0000000000000078 00000078 [ 2] .foo NOBITS 0000000000000098 00000098 to % ~/Dev/binutils-gdb/out/release/ld/ld-new orphan-13[abc].o -T orphan-13.ld && readelf -S a.out | grep foo [ 1] .foo NOBITS 0000000000000078 00000078 I think this is a good move. I have checked `.foo (TYPE=SHT_NOBITS) : {}` which already uses just one output section. I think in the future it makes sense to report a warning when NOBITS changes the section type from SHT_PROGBITS to SHT_NOBITS. This kind of section type change is likely not what the user expects.