How to run record instruction-history and function-call-history in GDB?

Question

(EDIT: per the first answer below the current \"trick\" seems to be using an Atom processor. But I hope some gdb guru can answer if this is a fundamental limitation, or whet

Answer 1

At least a partial answer (for the "am I doing it wrong" aspect) - from gdb-7.6.50.20140108/gdb/NEWS

* A new record target "record-btrace" has been added.  The new target
  uses hardware support to record the control-flow of a process.  It
  does not support replaying the execution, but it implements the
  below new commands for investigating the recorded execution log.
  This new recording method can be enabled using:

record btrace

  The "record-btrace" target is only available on Intel Atom processors
  and requires a Linux kernel 2.6.32 or later.

* Two new commands have been added for record/replay to give information
  about the recorded execution without having to replay the execution.
  The commands are only supported by "record btrace".

record instruction-history      prints the execution history at
                                instruction granularity

record function-call-history    prints the execution history at
                                function granularity

It's not often that I envy the owner of an Atom processor ;-)

I'll edit the question to refocus upon the question of workarounds or plans for future support.

Answer 2

It seems that there is no other solution except a CPU that supports it.

More precisely, your kernel has to support Intel Processor Tracing (Intel PT). This can be checked in Linux with:

grep intel_pt /proc/cpuinfo

See also: https://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean

The commands only works in record btrace mode.

In the GDB source commit beab5d9, it is nat/linux-btrace.c:kernel_supports_pt that checks if we can enter btrace. The following checks are carried out:

• check if /sys/bus/event_source/devices/intel_pt/type exists and read the type
• do a syscall (SYS_perf_event_open, &attr, child, -1, -1, 0); with the read type, and see if it returns >=0. TODO: why not use the C wrapper?

The first check fails for me: the file does not exist.

Kernel side

cd into the kernel 4.1 source and:

git grep '"intel_pt"'

we find arch/x86/kernel/cpu/perf_event_intel_pt.c which sets up that file. In particular, it does:

if (!test_cpu_cap(&boot_cpu_data, X86_FEATURE_INTEL_PT))
    goto fail;

so intel_pt is a pre-requisite.

How I've found kernel_supports_pt

First grep for:

git grep 'Target does not support branch tracing.'

which leads us to btrace.c:btrace_enable. After a quick debug with:

gdb -q -ex start -ex 'b btrace_enable' -ex c --args /home/ciro/git/binutils-gdb/install/bin/gdb --batch -ex start -ex 'record btrace' ./hello_world.out

Virtual box does not support it either: Extract execution log from gdb record in a VirtualBox VM

Intel SDE

Intel SDE 7.21 already has this CPU feature, checked with:

./sde64 -- cpuid | grep 'Intel processor trace'

But I'm not sure if the Linux kernel can be run on it: https://superuser.com/questions/950992/how-to-run-the-linux-kernel-on-intel-software-development-emulator-sde

Other GDB methods

More generic questions, with less efficient software solutions:

• call graph: List of all function calls made in an application
• instruction trace: Displaying each assembly instruction executed in gdb