From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.155.67.158]) by sourceware.org (Postfix) with ESMTPS id 92104385C017 for ; Sat, 22 Jul 2023 03:48:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 92104385C017 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tinylab.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tinylab.org X-QQ-mid: bizesmtp79t1689997679trv8okn3 Received: from archlinux.tail147f4.ts.net ( [219.246.90.177]) by bizesmtp.qq.com (ESMTP) with id ; Sat, 22 Jul 2023 11:47:57 +0800 (CST) X-QQ-SSF: 01200000000000202000000A0000000 X-QQ-FEAT: cy+SGFpNa8eickfyEJFcDpxqlBElThwMSsDdHPW77mTsq8/XjllK6Cc68DK1e dknYAH8ItsF6nLAPWezju3aggzK+tYMT37srL21lqjq51a5wuTLqMp2bzNNf1532CfO2ufC ePXU3XH7gPImHtWdTLub37RrbS42DJ4qGe2CH+h5wt2/XqxC64iL3W9XrkKgZHn0kkUeBPM s4Q2btsyky91vx0B77/LtSfhJBufXmvfgSvoh29Yr4X3N+iwME2a2bUV58uKxy1EZcTMa/8 D4JZHMvZoVNZtwEct+oVasXr9mHwhe0cZAbuj4VcZF+/S7Qxc1DCE/gMNFGJbY7gFHTlwlJ DHRp/5bkcY0MUTuKBU= X-QQ-GoodBg: 0 X-BIZMAIL-ID: 12087908707681731192 From: Tan Yuan To: amodra@gmail.com Cc: binutils@sourceware.org, jbeulich@suse.com, falcon@tinylab.org Subject: Re: [PATCH 0/1] gas: add new command line option --no-group-check Date: Sat, 22 Jul 2023 11:47:56 +0800 Message-ID: <828101CD9EDF8D8E+20230722034757.3071005-1-tanyuan@tinylab.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrgz:qybglogicsvrgz5a-1 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,RCVD_IN_ABUSEAT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,RCVD_IN_PBL,RCVD_IN_SBL_CSS,RCVD_IN_XBL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, Thanks for your reply. > On Fri, Jul 21, 2023 at 11:14:20PM +0800, Tan Yuan wrote: > > Hi, list > > > > This patch introduces a new option that allows suppressing the warning > > when attaching a group to a section that already belongs to a group. > > Is this alternative patch sufficient for the kernel usage? > > * config/obj-elf.c (obj_elf_attach_to_group): Don't warn if > group name matches current group for section. > > diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c > index 753a929fb14..dc05b35ee99 100644 > --- a/gas/config/obj-elf.c > +++ b/gas/config/obj-elf.c > @@ -1088,8 +1088,9 @@ obj_elf_attach_to_group (int dummy ATTRIBUTE_UNUSED) > > if (elf_group_name (now_seg)) > { > - as_warn (_("section %s already has a group (%s)"), > - bfd_section_name (now_seg), elf_group_name (now_seg)); > + if (strcmp (elf_group_name (now_seg), gname) != 0) > + as_warn (_("section %s already has a group (%s)"), > + bfd_section_name (now_seg), elf_group_name (now_seg)); > return; > } The alternative patch enabling attachment to the same group feasible while keeping the changes minimal. The problem is, when macro which contains ".attach_to_group" expanded multiple times within a function, we cannot make the group name the same. We hope to modify code like this in the kernel: + #define ___PASTE(a,b) a##b + #define __PASTE(a,b) ___PASTE(a,b) + #define __UNIQUE_ID_GROUP __PASTE(__PASTE(__COUNTER__, _), __LINE__) #define __ASM_EXTABLE_RAW(insn, fixup, type, data) \ - ".pushsection __ex_table, \"a\"\n" \ + ".attach_to_group " __stringify(__UNIQUE_ID_GROUP) "\n" \ + ".pushsection __ex_table, \"a?\"\n" \ "…" \ ".popsection\n" void example_func() { asm(__ASM_EXTABLE_RAW(insn, fixup, type, data)); asm(__ASM_EXTABLE_RAW(insn, fixup, type, data)); } This leads to the problem that when the macro is expanded in different locations of a function, the group name becomes different. Below, we have provided a detailed explanation as to why it is not feasible to utilize the same group name. We want to find a way to obtain a function-level unique string as the group name. The term "function-level unique" means that in different functions, the macro expands as a different string, and within the same function, it results in the same string. The obvious approach is to use the function name as the function-level unique string. However, "__func__" is not a macro; instead, it is defined as "static const char func[]". We can only obtain "func" during compilation, but not during preprocessing. Thus, I haven't found a way to make something like ".attach_to_group func" work. Or is there any way to get the name of the section and use it as the group name? Alternatively, we have considered using "ifdef" to avoid multiple expansions of ".attach_to_group,". It can be expanded in a file multiple times, and it is supposed to be expanded in a function once, which still requires a function-level unique string as a marker. Therefore, the best solution I can think of at the moment is to add an option to disable the warning for duplicate attach to group operations. I would greatly appreciate any other advice. Thanks Tan Yuan > > > > -- > Alan Modra > Australia Development Lab, IBM