From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E61AFC433E0 for ; Wed, 10 Feb 2021 02:33:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B35E164E32 for ; Wed, 10 Feb 2021 02:33:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235396AbhBJCcy (ORCPT ); Tue, 9 Feb 2021 21:32:54 -0500 Received: from smtprelay0111.hostedemail.com ([216.40.44.111]:34784 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S235304AbhBJCLQ (ORCPT ); Tue, 9 Feb 2021 21:11:16 -0500 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 1088312611; Wed, 10 Feb 2021 02:10:25 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: chin80_570a5ce2760c X-Filterd-Recvd-Size: 5662 Received: from [192.168.1.159] (unknown [47.151.137.21]) (Authenticated sender: joe@perches.com) by omf16.hostedemail.com (Postfix) with ESMTPA; Wed, 10 Feb 2021 02:10:24 +0000 (UTC) Message-ID: <2b4805f6ca2b44f4195b6fdba4f82d5e90ab1989.camel@perches.com> Subject: Re: [PATCH v4] checkpatch: do not apply "initialise globals to 0" check to BPF progs From: Joe Perches To: Song Liu , linux-kernel@vger.kernel.org Cc: bpf@vger.kernel.org, Andy Whitcroft Date: Tue, 09 Feb 2021 18:10:22 -0800 In-Reply-To: <20210209211954.490077-1-songliubraving@fb.com> References: <20210209211954.490077-1-songliubraving@fb.com> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2021-02-09 at 13:19 -0800, Song Liu wrote: > BPF programs explicitly initialise global variables to 0 to make sure > clang (v10 or older) do not put the variables in the common section. Acked-by: Joe Perches So the patch is OK now, but I have a question about the concept: Do you mean that these initialized to 0 global variables should go into bss or another section? Perhaps it'd be useful to somehow mark variables into specific sections rather than bss when initialized to 0 and data when not initialized to 0. $ clang --version clang version 10.0.0 (git://github.com/llvm/llvm-project.git 305b961f64b75e73110e309341535f6d5a48ed72) Target: x86_64-unknown-linux-gnu Thread model: posix $ cat t_common.c int a = 0; int b = 1; int foo_a(void) { return a; } int foo_b(void) { return b; } $ clang -c -O3 t_common.c $ objdump -x t_common.o t_common.o: file format elf64-x86-64 t_common.o architecture: i386:x86-64, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x0000000000000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000017 0000000000000000 0000000000000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .bss 00000004 0000000000000000 0000000000000000 00000058 2**2 ALLOC 2 .data 00000004 0000000000000000 0000000000000000 00000058 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .comment 00000068 0000000000000000 0000000000000000 0000005c 2**0 CONTENTS, READONLY 4 .note.GNU-stack 00000000 0000000000000000 0000000000000000 000000c4 2**0 CONTENTS, READONLY 5 .eh_frame 00000040 0000000000000000 0000000000000000 000000c8 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 6 .llvm_addrsig 00000000 0000000000000000 0000000000000000 00000210 2**0 CONTENTS, READONLY, EXCLUDE SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 t_common.c 0000000000000000 l d .text 0000000000000000 .text 0000000000000000 g O .bss 0000000000000004 a 0000000000000000 g O .data 0000000000000004 b 0000000000000000 g F .text 0000000000000007 foo_a 0000000000000010 g F .text 0000000000000007 foo_b RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000002 R_X86_64_PC32 a-0x0000000000000004 0000000000000012 R_X86_64_PC32 b-0x0000000000000004 RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 0000000000000020 R_X86_64_PC32 .text 0000000000000034 R_X86_64_PC32 .text+0x0000000000000010 Perhaps instead something like: $ cat t_common_bpf.c __attribute__((__section__("bpf"))) int a = 0; __attribute__((__section__("bpf"))) int b = 1; int foo_a(void) { return a; } int foo_b(void) { return b; } $ clang -c -O3 t_common_bpf.c $ objdump -x t_common_bpf.o t_common_bpf.o: file format elf64-x86-64 t_common_bpf.o architecture: i386:x86-64, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x0000000000000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000017 0000000000000000 0000000000000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 bpf 00000008 0000000000000000 0000000000000000 00000058 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .comment 00000068 0000000000000000 0000000000000000 00000060 2**0 CONTENTS, READONLY 3 .note.GNU-stack 00000000 0000000000000000 0000000000000000 000000c8 2**0 CONTENTS, READONLY 4 .eh_frame 00000040 0000000000000000 0000000000000000 000000c8 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 .llvm_addrsig 00000000 0000000000000000 0000000000000000 00000210 2**0 CONTENTS, READONLY, EXCLUDE SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 t_common_bpf.c 0000000000000000 l d .text 0000000000000000 .text 0000000000000000 g O bpf 0000000000000004 a 0000000000000004 g O bpf 0000000000000004 b 0000000000000000 g F .text 0000000000000007 foo_a 0000000000000010 g F .text 0000000000000007 foo_b RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000002 R_X86_64_PC32 a-0x0000000000000004 0000000000000012 R_X86_64_PC32 b-0x0000000000000004 RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 0000000000000020 R_X86_64_PC32 .text 0000000000000034 R_X86_64_PC32 .text+0x0000000000000010