Re: How to use bts recording?

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