Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp3828295rdb; Thu, 14 Sep 2023 04:08:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEgWB0Pam8mAIijOSLrCu3mbnqOjWNZ9uXnSCYwkAKwMI56dULjafxQqgsZlRRJ3sMSVaN+ X-Received: by 2002:a05:6a00:2289:b0:68a:553a:c0da with SMTP id f9-20020a056a00228900b0068a553ac0damr5422364pfe.24.1694689682086; Thu, 14 Sep 2023 04:08:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694689682; cv=none; d=google.com; s=arc-20160816; b=f5PUB22NO3iyhCGnfF7HzHGoRkzTHPCZ82nsx56ABkL69v4/HLvsZFUKdZ+fMNi460 1bqIeCetEFhU4LBy628nu07jobqkZgk8FCMcsB8E6p2YZy+Y12bdQJDezu1IzOaxRQzR rPvHIzedY7+KgqrqJLjVskoJReh2NMfXDrTi1zh+FaKlHjy79d4YHuO3uYzYXbNPtH0E vGIr2LGKtB2e0jJP5VirfYmAnNevi8JwGw0nCIl253iq9wfSL0YBdQFmpAzsoFcuw3Il iKGs05GyVKHWR4Q/4inA9BlRg+V1s1OddZtN0DNluaiHSGDnjRhc4ZuJn50VXRC1giJV p8bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=UVXZO7W2/QCPPSKGU4H/Fe8rerhR3cSJZGyrzhYOvmk=; fh=5tSX/k+58WjTWfsRZN4RRiEUeMY4Sk3k66SYWtRhpI8=; b=Ja1V56OQ6t2eyOpxwYCeNccQ0QJOKZy/dUdKEGaDretnX8qWAVqwWp9ywz8GzEQRAx apRWrHtQ2IbipfNgnnzxglBw6wjY/tJgEM/XJsHTi60apUUnRh8gM4Uqc1AdsyjfGHgR mqN1EjSfyMs1zo7+4wP6ahksQusRRncwzUQ6udJAleOS8cu90Y47ZKoOOZgvuequBmGo YsZ5B/f8HE1hWqNkRnqcnVY8Oun0pnGAezWix792yXsjI5mhCrByBq3t50xNcjLmWLGM 8j6hqYHplD+4+yoVldChFrLLlwXy61IWcnGuHRmhNBac78MUrZLFgOwkoTzkVLgGjy09 XXsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=c03TtHJu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id a16-20020a056a001d1000b0068e47f319d9si1357421pfx.280.2023.09.14.04.07.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 04:08:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=c03TtHJu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id A56098075921; Wed, 13 Sep 2023 01:06:25 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238810AbjIMIGY (ORCPT + 99 others); Wed, 13 Sep 2023 04:06:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238803AbjIMIGT (ORCPT ); Wed, 13 Sep 2023 04:06:19 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B4A2198A; Wed, 13 Sep 2023 01:06:15 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 3AEA9215EE; Wed, 13 Sep 2023 08:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1694592374; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UVXZO7W2/QCPPSKGU4H/Fe8rerhR3cSJZGyrzhYOvmk=; b=c03TtHJub3JTBDiTKedrTnB0QDOzSi2Gsnh8FR5Ihkc9N8R+HeZbMLOSnj0ZzzdNveD47f 5cMbweHy0EppeoPtIdyuib6XERK/XWEoh8bu7YFwf1zvUvNCT3Hqj4lP6BhKSkJ/01PqUb Jga5QzIe7QA9YgzG9VuBwblqEZY0XkE= Received: from suse.cz (pmladek.udp.ovpn2.prg.suse.de [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 5A20E2C146; Wed, 13 Sep 2023 08:06:12 +0000 (UTC) Date: Wed, 13 Sep 2023 10:06:12 +0200 From: Petr Mladek To: Alessandro Carminati Cc: Alexander Lobakin , Masami Hiramatsu , Steven Rostedt , Daniel Bristot de Oliveira , Josh Poimboeuf , Masahiro Yamada , Luis Chamberlain , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , Nick Alcock , Kris Van Hees , Eugene Loh , Francis Laniel , Viktor Malik , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH v3] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms Message-ID: References: <20230828080423.3539686-1-alessandro.carminati@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Sep 2023 01:06:25 -0700 (PDT) On Tue 2023-09-12 16:18:00, Alessandro Carminati wrote: > ha scritto: > > From: Alessandro Carminati (Red Hat) > > > sample from new v3 > > > > > > ~ # cat /proc/kallsyms | grep gic_mask_irq > > > ffffd0b03c04dae4 t gic_mask_irq > > > ffffd0b03c04dae4 t gic_mask_irq@_drivers_irqchip_irq-gic_c_167 > > > ffffd0b03c050960 t gic_mask_irq > > > ffffd0b03c050960 t gic_mask_irq@_drivers_irqchip_irq-gic-v3_c_404 > > > > BTW, why normalize them? Why not just > > > > gic_mask_irq@drivers/irqchip/... > > > > Aaaaand why line number? Line numbers break reproducible builds and also > > would make it harder to refer to a particular symbol by its path and > > name since we also have to pass its line number which may change once > > you add a debug print there, for example. > > OTOH there can't be 2 symbols with the same name within one file, so > > just path + name would be enough. Or not? I am afraid that there can be more symbols with the same name in a single source file. For example, static variables defined inside functions: $> cat >test-duplicate-symbols.c < void a(void) { static int duplicate_var = 100; printf("%s: %d\n", __func__, duplicate_var); } void b(void) { static int duplicate_var = 200; printf("%s: %d\n", __func__, duplicate_var); } int main(int argc, char *argv) { a(); b(); } EOT $> gcc -o test-duplicate-symbols test-duplicate-symbols.c $> ./test-duplicate-symbols a: 100 b: 200 $> objdump -t test-duplicate-symbols | grep duplicate test-duplicate-symbols: file format elf64-x86-64 0000000000000000 l df *ABS* 0000000000000000 test-duplicate-symbols.c 0000000000402018 l O .data 0000000000000004 duplicate_var.2190 000000000040201c l O .data 0000000000000004 duplicate_var.2195 > Regarding the use of full file paths and line numbers for symbol decoration, > it indeed provides the highest level of uniqueness for each symbol. > However, I understand your point that this level of detail might be more than > necessary. > > This approach was implemented in response to a specific request expressed in > the live-patching list, and I wanted to ensure we met those requirements. > I am open to revisiting this aspect, and I am willing to accommodate changes > based on feedback. Yeah, livepatching needs to be able to find any symbol which might need to be accessed from the livepatch. The line number is perfectly fine for livepatching because there is 1:1:1 relationship between the kernel sources, binary, and livepatch. And it might be even useful for the tracing. It helps to find and investigate the traced code easily. Hmm, I understand that it complicates the live for the trace tooling. I wonder if we could allow searching the symbols with a pattern, e.g. the bash style "duplicated_symbol_name-source_file_c*" > If you believe that simplifying the format to just path + name would be more > practical, or if you think that eliminating line numbers is a better choice > to avoid potential issues while debugging builds, I'm open to considering > these adjustments. > Additionally, I've interpreted and implemented Francis's suggestion as making > the separator a configurable option, but maybe a proper format string here, > would be more appropriate. Please, do not make the format configurable. I think that it will cause more harm than good. It would make the life more complicated for developing tracing tools. The tools would need to support all the formats as well. Or they would support only some and will not be able to trace kernels with the others. Both is bad. Anyway, thanks a lot for working on this. Best Regards, Petr