Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp1399592imn; Sun, 31 Jul 2022 05:40:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR5XpOUjVebGxxFeS40EKvOgPX6frftk7scR0w47cNm4clkEPuXBInA9G9bJVUQ1sw7F0DHZ X-Received: by 2002:a17:906:cc48:b0:730:7545:bf51 with SMTP id mm8-20020a170906cc4800b007307545bf51mr1321993ejb.247.1659271249976; Sun, 31 Jul 2022 05:40:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659271249; cv=none; d=google.com; s=arc-20160816; b=UbO0ctuurZoqFeTh4n843wkGFUOskEWaankwqy330sltkNYL8iaUhZf9G9oOGZyRou FaGaDpqQKCnirHLS2ds9+uI0Eu2RquV1acM+NKfKtrQp7PcjMLukeDvfYJw+Pz72QOMZ uLKulU5c2/hMASiwXm58TpWR0aR4JUe0tfto9wZsTx27kvp5lSY3FqnHJBiXpZjauzHe 7tE9zzCvJiNzeT04RjXMm8utjIFICAbN+ohDghiAl8cQTZnUNfD9mzEnX+1MhWOssCdP F7uMs2vMDU24f5MyU7IPtmAsOA5yYzdl+OyvE26Vc09B8+N0fqMVyL+29TdrSH1V4kYz l+kA== 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=zxVdgJ1vux8TImW4FL6YxoljQySxzKuzGy0keBd2VZs=; b=pnlOLcP3eXf7n71MoEcUdQBsBYMXEdm6V5Kt6/PW8+DdILsZvXdi2DBe1Xjsk+flIQ C5KNwMmsQ6UCJ1uDH61eib5FcMx5+pM9tBASZStGjbGeRWZptqVMOxMEe5PrNu1Ijng1 mE5poO2k+OvGTIjzSQJMyX9NkLQTY91Sh9STuzM9BwevrZBCNf5AeDjq30+peDH2hZ5i rzsBxZZEgdeCxJWNioB1EbrWsidEW1IuPw18TXKp/3UltFn52BnNz0wCcuhd9cP03aRN dI+kUUQtAh/28+suHLWupyUNOos4p8er1DaaJgn8jfuUUPuhas/jqb3z+DxZVFKui6Rj t2CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hrxQFkCZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w20-20020a056402269400b0043d84f9413dsi1958546edd.604.2022.07.31.05.40.24; Sun, 31 Jul 2022 05:40:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hrxQFkCZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236863AbiGaMhO (ORCPT + 99 others); Sun, 31 Jul 2022 08:37:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236907AbiGaMhM (ORCPT ); Sun, 31 Jul 2022 08:37:12 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5572DFA2 for ; Sun, 31 Jul 2022 05:37:10 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id v131-20020a1cac89000000b003a4bb3f786bso430733wme.0 for ; Sun, 31 Jul 2022 05:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zxVdgJ1vux8TImW4FL6YxoljQySxzKuzGy0keBd2VZs=; b=hrxQFkCZKXjrqETbsKn775YJhevjC8fXOkPKFmvJIwughHVOAc0Va5Ye54CexdAbjU NhRt1YEQDznNumcmFp+UjMxYVDOd404Js2SfF+oFtYKBQ6e3hYH3OBK4n9xTE3fhv98R lZkK6e+f0bQT3XIG/Gy7kuPsY5HPUKvXcyx/xBlGA4cKrnNLhPeYY4Xurza93Y05b39F RP6aSFjh+LEzSrMZNZ+Y2TvrVZwiB8bkiKs7Q2c+mBODFvezaRUw8S51st6XhCRQF5t2 uQn90+eK9GQQP4KDnBO102rdeHEXrvk98b4fp9W6BJ3vK+/7lVVolXTt5vGCjMTW6s5w QO2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zxVdgJ1vux8TImW4FL6YxoljQySxzKuzGy0keBd2VZs=; b=SL53ckxoO57aNHWrr2DqoNCBWCoOBjPbDedl6IwFKw0FpvD5biCUlRQHOFMHNCcguC +mZ92vSmcGT9MPp9hVB47RXGnl9OYn2UVj1fnK8rDUbGJwRJdw4WjtPlKizg/bKKJox5 efdADeKiHxeRKosjeFs2oOlx7q/TRsT1W0N5LTL0ymM/VIYmVtb8hUoVhr2xiaIz/AQV VGIz2QnHISKOiD4fO/n2ykgtseKQau2wuFl3J3aggMfBDIY2PyyKKft/e8i6nUPXwEpS S9f4MUI7hPKUFYO9LLyu6lgFbq/Bc3Easpeo8CYhL6MPPYrgqVLUmO3fWaOSzFAcOHCh KqAQ== X-Gm-Message-State: AJIora901SePhE3KRsZbSEVu9K9spZjo4s6bwi4THVHHb2PJpqPNZq0B 8H8sIP+nJtKlRKEG5iJVJfu4MA== X-Received: by 2002:a05:600c:2652:b0:3a3:2a3e:a2de with SMTP id 18-20020a05600c265200b003a32a3ea2demr8460316wmy.174.1659271029326; Sun, 31 Jul 2022 05:37:09 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([167.71.129.183]) by smtp.gmail.com with ESMTPSA id n186-20020a1ca4c3000000b003a2d87aea57sm15175048wme.10.2022.07.31.05.37.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Jul 2022 05:37:08 -0700 (PDT) Date: Sun, 31 Jul 2022 20:37:02 +0800 From: Leo Yan To: Ian Rogers Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , Ingo Molnar , Mark Rutland , Jiri Olsa , Namhyung Kim , Alexander Shishkin , Fangrui Song , Chang Rui , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] perf symbol: Correct address for bss symbols Message-ID: <20220731123702.GA205142@leoy-ThinkPad-X240s> References: <20220724060013.171050-1-leo.yan@linaro.org> <20220724060013.171050-2-leo.yan@linaro.org> <20220730093819.GA574473@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,URI_HEX autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 30, 2022 at 08:21:10AM -0700, Ian Rogers wrote: [...] > > On the other hand, I can accept to simply change pr_warning() to > > pr_debug4() to avoid warning flood, the log still can help us to find > > potential symbol parsing issue, so far they are not false-positive > > reporting. > > Thanks, I suspect the ELF that the Java agent has created isn't good. > The Java agent is part of perf as and so is the ELF file generation > code: > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/genelf.c?h=perf/core#n367 I think it's no need to change the function jit_write_elf(), please see below comment. > I took a quick look but most of the logic is in libelf - it seems less > obvious the bug would be there rather than perf. Could you take a > look? Ideally there'd be a quick fix that keeps all the benefits of > your change and the jvmti code working. A bit more finding for java JIT symbols. Let's see below two samples: 6.72% java /home/leoy/.debug/jit/java-jit-20220731.XXKRpgmR/jitted-214330-29.so 0x5b54 B [.] Interpreter 0.90% java /home/leoy/.debug/jit/java-jit-20220731.XXKRpgmR/jitted-214330-3475.so 0x4fc B [.] jdk.internal.math.FloatingDecimal$BinaryToASCIIBuffer.dtoa(int, long, int, boolean) I can see the DSO "jitted-214330-29.so" only contains a java JIT symbol "Interpreter", and I also observed the same behavior for other JIT symbols, e.g. jitted-214330-3475.so only contains the symbol "jdk.internal.math.FloatingDecimal$BinaryToASCIIBuffer.dtoa(int, long, int, boolean)". We always see these JIT symbols always have the consistent start file address, but this would not introduce conflit since every JIT symbol has its own DSO rather than share the same DSO. I think now I understand your meaning, and your below change is fine for me, I tested it and confirmed it can show up java JIT symbols properly. Just a comment, it would be better to add a comment for why we need to add symbols when failed to find program header, like: if (elf_read_program_header(syms_ss->elf, (u64)sym.st_value, &phdr)) { pr_debug4("%s: failed to find program header for " "symbol: %s\n", __func__, elf_name); pr_debug4("%s: adjusting symbol: st_value: %#" PRIx64 " " "sh_addr: %#" PRIx64 " sh_offset: %#" PRIx64 "\n", __func__, (u64)sym.st_value, (u64)shdr.sh_addr, (u64)shdr.sh_offset); /* * Fail to find program header, let's rollback to use shdr.sh_addr * and shdr.sh_offset to calibrate symbol's file address, though * this is not necessary for normal C ELF file, we still need to * handle java JIT symbols in this case. */ sym.st_value -= shdr.sh_addr - shdr.sh_offset; } else { ... } Could you send a formal patch for this? Thanks! Leo > > Thanks, > > Leo > > > > > ``` > > > --- a/tools/perf/util/symbol-elf.c > > > +++ b/tools/perf/util/symbol-elf.c > > > @@ -1305,16 +1305,21 @@ dso__load_sym_internal(struct dso *dso, struct > > > map *map, struct symsrc *syms > > > _ss, > > > > > > if (elf_read_program_header(syms_ss->elf, > > > (u64)sym.st_value, &phdr)) { > > > - pr_warning("%s: failed to find program > > > header for " > > > + pr_debug4("%s: failed to find program > > > header for " > > > "symbol: %s st_value: %#" PRIx64 "\n", > > > __func__, elf_name, > > > (u64)sym.st_value); > > > - continue; > > > + pr_debug4("%s: adjusting symbol: > > > st_value: %#" PRIx64 " " > > > + "sh_addr: %#" PRIx64 " > > > sh_offset: %#" PRIx64 "\n", > > > + __func__, (u64)sym.st_value, > > > (u64)shdr.sh_addr, > > > + (u64)shdr.sh_offset); > > > + sym.st_value -= shdr.sh_addr - shdr.sh_offset; > > > + } else { > > > + pr_debug4("%s: adjusting symbol: > > > st_value: %#" PRIx64 " " > > > + "p_vaddr: %#" PRIx64 " > > > p_offset: %#" PRIx64 "\n", > > > + __func__, (u64)sym.st_value, > > > (u64)phdr.p_vaddr, > > > + (u64)phdr.p_offset); > > > + sym.st_value -= phdr.p_vaddr - phdr.p_offset; > > > } > > > - pr_debug4("%s: adjusting symbol: st_value: %#" > > > PRIx64 " " > > > - "p_vaddr: %#" PRIx64 " p_offset: %#" > > > PRIx64 "\n", > > > - __func__, (u64)sym.st_value, > > > (u64)phdr.p_vaddr, > > > - (u64)phdr.p_offset); > > > - sym.st_value -= phdr.p_vaddr - phdr.p_offset; > > > } > > > > > > demangled = demangle_sym(dso, kmodule, elf_name); > > > ``` > > > > > > Thanks, > > > Ian > > > > > > > > > > > demangled = demangle_sym(dso, kmodule, elf_name); > > > > -- > > > > 2.25.1 > > > >