The SEP drivers weren't built and weren't installed:
hekto#ubuntu:/opt/intel/vtune_amplifier_xe/sepdk/src$ sudo ./insmod-sep -q
pax driver is not loaded.
socperf2_0 driver is not loaded.
sep4_0 driver is not loaded.
vtsspp driver is not loaded.
The Perf tool also wasn't built correctly (the kernel is customized one):
hekto#ubuntu:/opt/intel/vtune_amplifier_xe/sepdk/src$ perf -v
WARNING: perf not found for kernel 3.18.41-test
But - the VTune actually works, I can see profiling results. What kind of sampling is being used in this case? I don't see anything about that in the VTune GUI.
It uses user mode sampling by injecting into the app and setting profiling timers for each thread and then capturing IP and stack in signal handlers. see more https://software.intel.com/en-us/node/544072
Related
I'm trying to use GDB to debug Qemu running on m68k architecture. I am attempting to make some changes to Qemu source to add some functionality to m68k support, and I am trying to use GDB to test changes I have currently made. Important to note is that I am using Qemu v5.2.0-rc1, as that is the version of Qemu currently utilized in a larger system that I am concurrently working with. Currently, I am using qemu-system-m68k to run buildroot (uClinux kernel) on that architecture, using the "-s -S" options for gdb. In a separate terminal, I am trying to run GDB on that remote target using (gdb) target remote localhost:1234, but I am getting the following error message:
warning: Architecture rejected target-supplied description
The connection to the uClinux Qemu kernel seems to go okay, but I cannot connect to the remote host.
I have tried finding any possible solutions to this problem, including setting the GDB architecture (currently says i386, not sure if this is right), which does not work. I have no idea how to get GDB running on this m68k Qemu emulated Linux kernel, and any help would be great. Thanks!
The error message means that QEMU's gdb stub sent gdb a description of what the CPU is (mostly a list of registers), and gdb didn't understand it. One common cause of this is trying to debug with a gdb for the wrong architecture.
You need to use a gdb which is aware of the the target architecture. On Ubuntu there is a 'gdb-multiarch' package which has a gdb-multiarch binary that knows about more than just x86. Otherwise you might need to build gdb from source. You can check if your gdb knows about m68k by running it with no arguments and typing the command set arch m68k. If it replies The target architecture is assumed to be m68k then it's OK (and your issue is something more complicated); if it gives you an error (eg Undefined item: "m68k") then you need to use a different gdb.
Classic setup: There is a bootloader, and application, compiled separately. If everything is right, the bootloader jumps on the application.
I attach a probe, run the gdbserver, start gdb with the bootloader binary. If I run file application.elf then I lose my symbols for the bootloader.
How can I observe the handover, and what the application does exactly right after the jump, by running one instruction at a time?
Probably possible with an SWD commander by tracing the PC step-by-step and using addr2line to decode each step, but I'm hoping for a more proper way.
You can load the symbols with:
gdb add-symbol-file
I want to write my own hypervisor for Intel Platform based on an open project and I want understand how to debug it.
I have real stend to debug on, but it reboots at faults and it is hard to find mistake. I've found I could use QEMU/KVM with nested hypervisor to debug it. May be there are any other variants? VMware is hanging with faults, as I understand. On AMD platforms I have used SimNow.
It will be good if the host system will be Windows.
Thank you for advices.
It depends on your flavor. The couple Qemu/GDB is a good start. Here are some useful hints if your host platform is Intel CPU, you can:
start qemu like this : qemu-system-x86_64 -enable-kvm -cpu host -s -S .... Qemu will boot the hypervisor along with its gdbserver and pause it until it receives continue command from gdb.
Start GDB like this: gdb /path/to/hypervisor then, target remote :1234 to attach the gdb to the gdbserver
Use hbreak instead of break, but you have only 4 breakpoints left
From this point, you may continue the debugging as for a simple application
I am using Visual Studio 2013 with patch 4.
When I am trying to run a "performance and diagnostics" test for GPU profiling, the launcher immediately fails with the following output:
Profiling of 'Graphics Frame Capture' started.
Graphics Frame Capture has exited.
Profiling of 'Graphics Frame Capture' stopped.
Diagnostics session failed to start.
Failed to enable system trace session.
Mind you I can run the built-in graphics debugger without a problem on the same project.
What gives?`
I am running Windows 7 professional if it matters.
I want to monitor a process and everything it does (every signal it gives SIGINT what ever).
Is there anyway to do this?
I'm using Linux (Ubuntu 11 to be exact)
The strace unix command will do all that and more if you're looking for command-line monitoring.
It uses the ptrace system call infrastructure for monitoring which is in itself even more powerful: additionally allowing control of and interaction with the process. To quote from Wikipedia:
ptrace is used by debuggers (such as gdb and dbx), by tracing tools like strace and ltrace, and by code coverage tools. ptrace is also used by specialised programs to patch running programs, to avoid unfixed bugs or to overcome security features. It can further be used as a sandbox and as a runtime environment simulator (like emulating root access for non-root software).
If you want to do this monitoring programatically rather than from the command line, then ptrace is the solution for you.
strace ought to work, or something listed in the "Other Tools" section on that page.