From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id XX5dGQ168WEOKAAAWB0awg (envelope-from ) for ; Wed, 26 Jan 2022 11:42:53 -0500 Received: by simark.ca (Postfix, from userid 112) id 57CAA1F3B6; Wed, 26 Jan 2022 11:42:53 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 702C71EA69 for ; Wed, 26 Jan 2022 11:42:52 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B3592385E836 for ; Wed, 26 Jan 2022 16:42:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B3592385E836 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643215371; bh=MiqlMJzosiMqq3fGRaB22h3bF4sMB88k89KcS9T5smc=; h=Date:To:References:Subject:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=WbYCqNPWkUjGd+XYn7kdRR/NHPnX4U1A2TW+1WtByzIBDRUprh9k8PuOwJZ+V6rjA senasc7qolnOP5HorZpsLEVWfXhyuFYgjYkHREMMVrpeVlsyCTDfhujSa9WgGkdcTf qiEutpPtQmyMnX1vsF0XcEVIuqC3Uhq/vjX/fIr8= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id F05EE3864831 for ; Wed, 26 Jan 2022 16:41:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F05EE3864831 Received: from [2001:470:142:3::e] (port=36150 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nClM0-0004wD-3l; Wed, 26 Jan 2022 11:41:05 -0500 Received: from ip5f5a8abe.dynamic.kabel-deutschland.de ([95.90.138.190]:59982 helo=[192.168.111.41]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nClLj-0000XF-91; Wed, 26 Jan 2022 11:41:03 -0500 Message-ID: Date: Wed, 26 Jan 2022 17:40:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: "Metzger, Markus T" References: <40aebee9-d4ed-3a94-2341-cc17beeb6431@gnu.org> <290cd354-3de0-9c0a-5bd7-48cc2ba9173e@gnu.org> Subject: Re: How to use bts recording? In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Sobisch via Gdb Reply-To: Simon Sobisch Cc: "gdb@sourceware.org" Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Am 26.01.2022 um 13:41 schrieb Metzger, Markus T: > Hello Simon, > >> PT has the downside of GDB having to be configured for that - which I >> guess isn't common in distro versions - and somehow a manual build n the >> 4.x kernel where libipt was available also did not pick it up (will try >> to force it with a GDB 11.2 build soon, thanks for pointing out the >> configure flags; I've looked in the tarball in the ./configure file but >> that was in gdb/configure). > > Let's work on that, then. Fedora configures GDB with PT support and I thought RHEL would too. Not sure at which version they started. The Debian GDB maintainer promised to enable it but I have not checked, since. I've just rechecked current Debian, the gdb binary, which shows as GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git has a link to /usr/lib/x86_64-linux-gnu/libipt.so.2, so I guess it is in there. Running there actually does show a different message (gdb) record btrace Could not enable branch tracing for Thread 0x7ffff79833c0 (LWP 334): BTS support has been disabled for the target cpu. (gdb) record btrace pt Could not enable branch tracing for Thread 0x7ffff79833c0 (LWP 334): Failed to open /sys/bus/event_source/devices/intel_pt/type: No such file or directory. But this machine is an AMD one... Both messages are very clear - it would be nice to get those with GDB 11.x, too (not sure if they are produced by a Debian patch or by a different code path). >>>> How can I check for BTS support? >>> >>> Hardware support is enumerated by cpuid and published by the kernel in >> /proc/cpuinfo under flags (look for 'bts'). Same for PT (look for 'intel_pt'). >> >> That may be the reason that it wasn't picked up; those aren't in there: >> >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >> mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb >> rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable >> nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic >> movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor >> lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb >> stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq >> rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt >> xsavec xsaves arat pku ospke flush_l1d arch_capabilities >> bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf >> >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm >> constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid >> sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c >> rdrand hypervisor lahf_lm abm 3dnowprefetch arat fsgsbase bmi1 hle avx2 >> smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt > > Are you maybe using virtualization? Rechecked with the server team: yes, the old RHEL kernel runs on Redhat Virtualization Manager; the newer one on VMware vSphere. If someone knows how to enable Intel PT and/or BTS there I'd take a pointer and pass it to the server team. > [...] > > >> Thanks for trying to get this working, ideally we have some hints the >> next time someone looks out for this and can add a better error message >> for bts to GDB. > > If this turns out to be something that GDB can check with reasonable effort, > diagnosing this would certainly help. Like we do for perf_event_paranoid. I totally agree. The "only" missing parts are: * How could GDB check this? * Who applies this change, possibly directly after the bts error is recognized? I'm available for testing a patched GDB 11.2 on both kernels :-) > Regards, > Markus. > Intel Deutschland GmbH Thanks again, Simon