From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by sourceware.org (Postfix) with ESMTPS id E2684385DC00 for ; Sat, 4 Apr 2020 16:46:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E2684385DC00 Received: by mail-io1-xd31.google.com with SMTP id i3so10986035ioo.13 for ; Sat, 04 Apr 2020 09:46:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G54zm3Ntwinqn4T4PoD+5xQeyJndRrgbh2NFZKeUlWg=; b=UJ1DXWSIyTBFijwKLBJQnUkv5/FvrM4xOzd7sLeUCKNMT+pbF4VjA9L47K13cN8k4Q YIeMP70Os0NP4TFHjBne7L34m8rmIlYM0BG5jx5kj/Yc4KzbtK68m2vcQ2uhc5nvXkoR zBS6Nx0wyjuUan+j6NjdyNRvnEXQN9wC2NLscgHUohqNzpUy4nFhyyu5FmWLNOU2GdPO IopKAPsmeoYg+uTtdAYcrbzp6PesJhtjG5Mb9DOWXr+dzalq20c52pBKk68tRtCoN7Xn i4UYkdFafhY1uCTKlDTTuvRVm05bjFkjPSQoR5IuKfeVo0MutkGPo5CKFNUS2EvbGytA rl9w== X-Gm-Message-State: AGi0Pubb2MkAE5Cx08Ev19pOCmTUtQ1jZpBJI9WKkiOiEoqPhVeBePyN h81eyqhhDR7y5Tlx0sgBuvGbXxcl5SY6IgF5FA4= X-Google-Smtp-Source: APiQypKgtwIc8KkyFA7TpFYwv4gXgUSN5BYrEeKl0Mk2VLA3E+6vZnht7l0WM05aAFWvF1FzBJbKBDvHWohvlMiB0Rw= X-Received: by 2002:a02:7f82:: with SMTP id r124mr3408628jac.88.1586018792831; Sat, 04 Apr 2020 09:46:32 -0700 (PDT) MIME-Version: 1.0 References: <20200206073837.j4biw4rsbdy2siip@gmail.com> <20200206083347.GC5669@bubble.grove.modra.org> <20200206091914.5docw46nvgx7om6o@google.com> <20200206140912.GE5669@bubble.grove.modra.org> <20200210052104.GQ5669@bubble.grove.modra.org> <20200404163828.abhvjv5p26mobuda@gmail.com> In-Reply-To: <20200404163828.abhvjv5p26mobuda@gmail.com> From: "H.J. Lu" Date: Sat, 4 Apr 2020 09:45:57 -0700 Message-ID: Subject: Re: Empty section flags To: Fangrui Song Cc: Alan Modra , bd1976 llvm , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 04 Apr 2020 16:46:35 -0000 On Sat, Apr 4, 2020 at 9:38 AM Fangrui Song wrote: > > On 2020-04-04, H.J. Lu wrote: > >On Tue, Mar 3, 2020 at 1:20 PM Fangrui Song wrote: > >> > >> On Sun, Feb 9, 2020 at 9:21 PM Alan Modra wrote: > >> > > >> > On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: > >> > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more > >> > > consistent to error in all cases - even in the case of different group > >> > > signatures. The only exception would need to be for the special section > >> > > names (.text, .debug_str, etc...) that the assembler has special knowledge > >> > > of (as you explained). > >> > > >> > Yes, let's see how that goes. > >> > https://sourceware.org/ml/binutils/2020-02/msg00129.html > >> > > >> > > I wonder why creating multiple sections with the > >> > > same name for section directives with different group signatures was > >> > > implemented - why not just require the use of a distinct section name for > >> > > these? > >> > > >> > I think plain ".text" for a group's text section is fine. Distict > >> > names would just be yet another thing to track for a group. > >> > > >> > > Or, now that GNU has the ",unique,N" assembly extension ( > >> > > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be > >> > > used if the section name is fixed - it would then be explicit in the source > >> > > code that another section with the same name will be created. > >> > > >> > Perhaps, but we aren't designing a new toolchain. Backwards > >> > compatibility can't be discarded without compelling reasons. > >> > > >> > -- > >> > Alan Modra > >> > Australia Development Lab, IBM > >> > >> For empty flags, should there be an error as well? > >> > >> .section .foo,"ax",@progbits; .byte 1 > >> .section .foo,"",@progbits; .byte 2 # no diagnostic > >> .section .foo,"a",@progbits; .byte 3 # Error: changed section > >> attributes for .foo > >> > >> Context: https://github.com/ClangBuiltLinux/linux/issues/913 > >> > >> I lean toward an error for consistency, and I will try making the LLVM > >> MC side rule stick. > > > >[hjl@gnu-cfl-2 tmp]$ cat x.s > >.section .foo,"",@progbits; .byte 2 > >[hjl@gnu-cfl-2 tmp]$ gcc -c x.s > >[hjl@gnu-cfl-2 tmp]$ readelf -SW x.o | grep foo > > [ 4] .foo PROGBITS 0000000000000000 000040 > >000001 00 0 0 1 > >[hjl@gnu-cfl-2 tmp]$ > > > >Unless it is disallowed by gABI/psABI, assembler should allow it. > >Sometimes, I found a need to create odd object files, like zero-sized > >relocation section, for linker test. Assembler should have more > >flexibilities within gABI/psABI. > > > >-- > >H.J. > > Declaring a section with empty flags is fine. > My question is about re-declaring with empty flags when the first declaration has other flags: > > .section .foo,"ax",@progbits; .byte 1 > .section .foo,"",@progbits; .byte 2 # no diagnostic > .section .foo,"a",@progbits; .byte 3 # Error: changed section > > This is about the follow-up of > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=33176d912add7680277ad5e18af0e6303d9a7af8 [hjl@gnu-cfl-2 tmp]$ cat y.s .section .foo,"ax",@progbits .byte 1 .section .foo .byte 2 .section .foo,"",@progbits .byte 3 .section .foo,"ax" .byte 3 [hjl@gnu-cfl-2 tmp]$ gcc -c y.s [hjl@gnu-cfl-2 tmp]$ readelf -SW y.o | grep foo [ 4] .foo PROGBITS 0000000000000000 000040 000004 00 AX 0 0 1 [hjl@gnu-cfl-2 tmp]$ If section flags or type is unspecified/empty, GNU assembler uses the previous one if it exists. I think this behavior is quite reasonable. -- H.J.