From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13497 invoked by alias); 4 Mar 2020 06:40:03 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 13485 invoked by uid 89); 4 Mar 2020 06:40:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_INFOUSMEBIZ,MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:D*googlemail.com, H*RU:e400, HX-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:sk:0000000, H*F:D*me X-HELO: NAM10-BN7-obe.outbound.protection.outlook.com Received: from mail-bn7nam10olkn2031.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) (40.92.40.31) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Mar 2020 06:40:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PSqg0OyygwG4iWaOP2/YH194vBASxuk5MC4efgOWOMefPhX5q3txXFXxzErI9BtqXmNKtzebi7G6jM4H6Rk6xYzUmVyl+B++VaS39j/cTAXSVfESo/3XjFDyQCnlHlwsaEKdO3fkGlkg5mFGb72057gcB8z3GXWryOh9cBe9s057A77dJ2chXD1DnlaVqwQ8VF2dgye+kiYxGrm3tcRtj3GQ9LooeJib1MOvjwxfV9X0Ne7kvVyRz+kMKWU7XpxEbYpf0JVYSzZjF1WId4PFNifTBylamtWc0JfD6PA0LFpEqHjAVVjgLYaVgMoGZu90598nGnlRy03KvzaPt1eIOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9htUAthmkWg9Dex8Frq6ns4hW+6xQIoHa20Ut/RQMg=; b=TVA4VYwYE+th+hdLIWt78L+wBeQ4nZ8W1lubL81A4r8xu81KlfF1quhCKHHCfMFQpI+/2PkqzINCBK+cWEqI10GsG6kqtEXg4o54MuDjpgOpk/W5vvXEgiy8epweyhhMr7D0qWnwHgCUAx2gttU5PT1g6TvNoh8iRwsaJl8vOUHpfF2vgb85iKbiOtEL/UfbAPUhRV3J7xHl+GXEc4gdKejdBNDGYXJNxzMLWVKw3OKOUFolCFTd+kecKsocB9QHJzRcSzR1Ay/glM6OaMysp+TdAwf998Hy/MnwliptLFcXx9JY3CwT9w6ExoX4Vf7RqyPuaU3kuDHW2K0alw1zrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=maskray.me; dmarc=pass action=none header.from=maskray.me; dkim=pass header.d=maskray.me; arc=none Received: from BN7NAM10FT007.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e8f::39) by BN7NAM10HT072.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e8f::224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Wed, 4 Mar 2020 06:39:58 +0000 Received: from BY5PR07MB7316.namprd07.prod.outlook.com (10.13.156.53) by BN7NAM10FT007.mail.protection.outlook.com (10.13.156.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Wed, 4 Mar 2020 06:39:58 +0000 Received: from BY5PR07MB7316.namprd07.prod.outlook.com ([fe80::9dce:8d96:403c:b724]) by BY5PR07MB7316.namprd07.prod.outlook.com ([fe80::9dce:8d96:403c:b724%6]) with mapi id 15.20.2772.019; Wed, 4 Mar 2020 06:39:58 +0000 References: <20200226052300.wazzfmivxta63vef@gmail.com> <20200226063003.4uvshiarho3wbkrl@google.com> <20200303223901.GO5384@bubble.grove.modra.org> <20200304055641.GT5384@bubble.grove.modra.org> In-Reply-To: <20200304055641.GT5384@bubble.grove.modra.org> From: Fangrui Song Date: Wed, 04 Mar 2020 06:40:00 -0000 Message-ID: Subject: Re: [ld] section address : ALIGN(align) and the maximum of input section alignments To: Alan Modra Cc: binutils , smithp352@googlemail.com Content-Type: text/plain; charset="UTF-8" Return-Path: i@maskray.me X-Microsoft-Original-Message-ID: MIME-Version: 1.0 Received: from mail-qk1-f172.google.com (209.85.222.172) by MN2PR05CA0066.namprd05.prod.outlook.com (2603:10b6:208:236::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.9 via Frontend Transport; Wed, 4 Mar 2020 06:39:57 +0000 Received: by mail-qk1-f172.google.com with SMTP id m9so581699qke.4 for ; Tue, 03 Mar 2020 22:39:57 -0800 (PST) X-Microsoft-Original-Message-ID: X-MS-Exchange-AntiSpam-MessageData: WQTbm+3kUZ6V3KVi8y/gWNOilGQXD0SyTAUr1uZY6OnKKM+o4XqFLIHEM4IQMq3gf1u7mevQ6TTlU7WUlEFycchjMre/xfL6/rpKtZqJ4f6gW3cjKIGT7O6QSuysX0nxXvl1wEFKGya4RZj4QXuKgg== X-SW-Source: 2020-03/txt/msg00074.txt On Tue, Mar 3, 2020 at 9:56 PM Alan Modra wrote: > > On Tue, Mar 03, 2020 at 03:58:12PM -0800, Fangrui Song wrote: > > Thanks. For the example below, do you agree with the comments in a.x below? > > > > % cat a.s > > .globl _start; _start: ret > > .section .data.rel.ro,"aw"; .balign 8; .byte 0 > > .data; .byte 0 > > .section .data2,"aw"; .balign 8; .byte 0 > > .section .data3,"aw"; .balign 32; .byte 0 > > .bss; .balign 32; .byte 0 > > % as a.s -o a.o > > > > % cat a.x > > SECTIONS { > > .text 0x10000 : { *(.text) } > > /* sh_addr is 0x10010. Specifying both address and ALIGN should be > > disallowed. */ > > .data.rel.ro . : ALIGN(16) { *(.data.rel.ro) } > > > > .data 0x20000 : { *(.data) } > > /* sh_addr is 0x20001. Should there be a warning that sh_addralign > > is 8? Even --warn-section-align does not warn. */ > > That is a bug. > > The ELF gABI says in part of sh_addralign: "The value of sh_addr must > be congruent to 0, modulo the value of sh_addralign." > > * elf.c (elf_fake_sections): Ensure sh_addralign is such that > sh_addr mod sh_addalign is zero. > > diff --git a/bfd/elf.c b/bfd/elf.c > index fcd84d2d17..c4d6718aaa 100644 > --- a/bfd/elf.c > +++ b/bfd/elf.c > @@ -3192,6 +3192,7 @@ elf_fake_sections (bfd *abfd, asection *asect, void *fsarg) > unsigned int sh_type; > const char *name = asect->name; > bfd_boolean delay_st_name_p = FALSE; > + bfd_vma mask; > > if (arg->failed) > { > @@ -3291,7 +3292,10 @@ elf_fake_sections (bfd *abfd, asection *asect, void *fsarg) > arg->failed = TRUE; > return; > } > - this_hdr->sh_addralign = (bfd_vma) 1 << asect->alignment_power; > + /* Set sh_addralign to the highest power of two given by alignment > + consistent with the section VMA. Linker scripts can force VMA. */ > + mask = ((bfd_vma) 1 << asect->alignment_power) | this_hdr->sh_addr; > + this_hdr->sh_addralign = mask & -mask; > /* The sh_entsize and sh_info fields may have been set already by > copy_private_section_data. */ > > > > .data2 . : { *(.data2) } > > /* sh_addr is 0x20020. The input section alignment wins. */ > > .data3 : ALIGN(16) { *(.data3) } > > /* sh_addr is 0x20030. Specifying both address and ALIGN should be > > disallowed. */ > > .bss . : ALIGN(16) { *(.bss) } > > } > > > > % ld.bfd -T a.x a.s -o a > > > > If specifying both Output Section Address and ALIGN is disallowed, > > there should be no "changing start of section" warning when > > --warn-section-align is not specified. Is my understanding correct? > > > > BTW, I filed a bug about duplicate "changing start of section" > > warnings https://sourceware.org/bugzilla/show_bug.cgi?id=25570 The implementation is complex. For users to understand, I think it will be helpful to have something more detailed in https://sourceware.org/binutils/docs/ld/Output-Section-Address.html#Output-Section-Address If my understanding is correct https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=233bf4f847b136705247e2f7f11bae41c72448a4 makes the output section address override sh_addralign computed from the maximum of input section alignments. So, generally the rules are: * The max of ALIGN and (the maximum of input section alignments) is taken. * The output section address overrides the above. If sh_addr % alignment != 0, set sh_addralign to the largest alignment that makes sh_addr%alignment=0 In this case, should the linker emit a warning? * ALIGN and the output section address cannot be specified at the same time. This is considered a linker script "undefined behavior". Users should not rely on a particular result. --warn-section-align may be out of place. It can be noisy for normal output section descriptions like .foo : ALIGN(16) { ... } without a preceding dot advancing to a multiple of 16.