From: Simon Sobisch <simonsobisch@gnu.org>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: How to use bts recording?
Date: Mon, 24 Jan 2022 10:58:59 +0100 [thread overview]
Message-ID: <290cd354-3de0-9c0a-5bd7-48cc2ba9173e@gnu.org> (raw)
In-Reply-To: <DM8PR11MB5749DF60DCDA68CA80E7E0C7DE5E9@DM8PR11MB5749.namprd11.prod.outlook.com>
Am 24.01.2022 um 10:27 schrieb Metzger, Markus T:
> Hello Simon,
>
>> using Intel(R) Xeon(R) Gold 6136 CPU on 4.18.0-80.el8.x86_64
>> and Intel(R) Xeon(R) E5-2697 v4 on 3.10.0-514.16.1.el7.x86_64
>
> Both kernels should support BTS and both processors should support BTS as well as PT. Given the choice, I'd always go with PT as the recording overhead is significantly lower and the trace format is much more compact giving you a significantly longer history.
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).
>> 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
> Kernel support for BTS would be checked by trying to enable it via perf_event_open as GDB does. I'm not aware of some kernel feature enumeration that one could use, instead.
>
> For PT, kernel support could be checked by looking at /sys/bus/event_source/devices/intel_pt/type, which gives the perf event type to be used for PT. BTS does not need that as it is using a fixed type.
There's no /sys/bus/event_source/devices/intel_pt/ either.
>> I've temporarily adjusted /proc/sys/kernel/perf_event_paranoid but even
>> -1 makes no difference.
>
> This is one common pitfall and that's why GDB is checking it and giving instructions how to fix it. The ' No such file or directory ' error you listed below may be a result of GDB trying to access that file and not finding it.
I guess this isn't the issue here , I can do
cat proc/sys/kernel/perf_event_paranoid
without any problems (showing 1 or 2, when not temporarily adjusted).
> One common reason for BTS not working is that someone on the system (including yourself) is using PT. The kernel does not allow them to be used at the same time, even by different processes.
>
> For PT, I'd ask you to try 'perf record -e intel_pt//u -- true' so see if PT is working in general on your system for your user. For BTS, I don't know of another tool we could try.
In both environment this raises
event syntax error:
'intel_pt//u'
\___ Cannot find PMU `intel_pt'. Missing kernel support?
I guess in this case there is no use in trying to build with intel-pt,
is it?
Not sure how to enable intel_pt in the kernel either.
> The error message should come from diagnose_perf_event_open_fail(), which means that the perf_event_open syscall failed. Could you check if perf is working at all on your system for your user?
Already checked that - works fine in general.
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.
Simon
>
> Regards,
> Markus.
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2022-01-24 9:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-21 15:18 Simon Sobisch
[not found] ` <DM8PR11MB57499C939B8E0B461F7489ECDE5E9@DM8PR11MB5749.namprd11.prod.outlook.com>
[not found] ` <eabf7025-9866-fcb9-507e-a0e29c0970e9@gnu.org>
2022-01-24 9:27 ` Metzger, Markus T
2022-01-24 9:58 ` Simon Sobisch [this message]
2022-01-26 12:41 ` Metzger, Markus T
2022-01-26 16:40 ` Simon Sobisch
2022-01-26 17:11 ` Metzger, Markus T
2022-01-26 18:12 ` Simon Sobisch
2022-01-27 10:45 ` Metzger, Markus T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=290cd354-3de0-9c0a-5bd7-48cc2ba9173e@gnu.org \
--to=simonsobisch@gnu.org \
--cc=gdb@sourceware.org \
--cc=markus.t.metzger@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).