public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

  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).