I am trying to use oprofile as profiling tool inside a virtual machine. However, if I do
operf
I get the following error:
Your kernel's Performance Events Subsystem does not support your processor type.
Please use the opcontrol command instead of operf.
I thus tried opcontrol. I did the following as root
opcontrol --deinit
rm /root/.oprofile/daemonrc
opcontrol --init
opcontrol --start
which returned the following error
Cannot find event CPU_CLK_UNHALTED
Using default event: CPU_CLK_UNHALTED:100000:0:1:1
Cannot find event CPU_CLK_UNHALTED
According to the bug tracker (http://sourceforge.net/p/oprofile/bugs/268/) what I did is already the workaround to get oprofile working in a VMware environment.
My OS is
Linux version 3.19.0-25-generic (buildd#lgw01-20) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015
Its installed in a virtual machine. The virtual machine software is VMware 7.1.1. The host OS is Mac OS X 10.10
I was having the same problem and found the solution at http://blogs.epfl.ch/category/3239 via oprofile on Linux running in a virtual machine
It seems by default when the oprofile kernel module is loaded by invoking
opcontrol --init
the timer support is not enabled.
The solution is to unload the kernel module
opcontrol --deinit
and load it manually, passing an option that enables timer support
modprobe oprofile timer=1
After doing that
opcontrol --start-daemon
worked for me.
Related
I'm using an m1 pro macbook pro.
Up until now, I used intel macbook.
My program is written in c/c++ and the target is ubuntu x86_64.
I tried running ubuntu x86 docker (qemu) and it's super slow - to the point it's unusable.
I have linux ubuntu (arm) installed using parallels and would like to compile for x86 target instead of arm.
How do I do it?
On Ubuntu, I would suggest an apt install gcc-x86-64-linux-gnu g++-x86-64-linux-gnu, and then invoking the installed compiler with the x86-64-linux-gnu prefix (for gcc, x86-64-linux-gnu-gcc) to create x86_64 binaries.
Do note that if you target x86_64 you won't be able to run the programs you build natively, but you should be able to package the binaries created for execution on an x86_64 machine.
Install docker-desktop on your mac and run this docker container with the command:
docker container run --platform=linux/amd64 -it -p 6080:6080 -e WIDTH=1920 -e HEIGHT=1080 yoas1/xubuntu-desktop:1.0
Don't forget to create volume to the code directory.
In your browser go to: http://localhost:6080/vnc.html to access the xubuntu desktop
Image on Dockerhub
I am using Ubuntu 16.04 on x86_64 workstation, and I'm cross-compiling a small demo program in C++, and deploying it to an embedded linux target running ARM architecture (environment-setup-cortexa9hf-neon-poky-linux-gnueabi, arm-poky-linux-gnueabi-g++).
I am able to successfully do this which gives me a debug session on commandline:
Target:
rpm -ivh gdbserver-7.10.1-r0.cortexa9hf_neon.rpm
gdbserver :9091 ${APPNAME}
Host:
sudo apt-get install gdb-multiarch
gdb-multiarch $APPNAME
target remote 192.168.0.212:9091
...
I can now use gdb-multiarch on commandline!
However from here... I really want to be able to use one of the many gdb frontend tools to provide a GUI to set breakpoints and step through the code (akin to gdbgui, or using vscode and configuring for a debugger). Are there any gdb frontend tools that specifically support gdb-multiarch?
Any tool I try, I believe no matter what it uses base gdb executable and gives this error because of mismatched architecture:
target remote 192.168.0.212:9091
Remote debugging using 192.168.0.212:9091
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000070fdff7e00000000c0fafc76100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
UPDATE 1 --
I can kinda sorta get this to work using ddd tool:
ddd --eval-command="target remote $MY_TARGET_IP:9091" --debugger gdb-multiarch
However! This is ancient and buggy, and I can't set breakpoints in loaded .so's right now with this.
I tried gdbgui with its options to specify debugger, but that's not currently working either. I filed a feature request report here:
https://github.com/cs01/gdbgui/issues/237
I found a way using gdbgui, but it required me to rebuild gdb from source code against my specific remote target architecture. Details of how I got it to work are here:
https://github.com/cs01/gdbgui/issues/237
Important bits in case the above link breaks:
TLDR Solution:
I was trying to rely on a prebuild gdb-multiarch from ubuntu apt repos, which didn't work. When I decided to download gdb and rebuild from source while configuring for arm-linux-gnuabi target arch.
Build method:
downloaded latest gdb source code
unzip it, go into folder, and build it like this:
./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=arm-linux-gnuabi && make -j8 && sudo make install
Important to note that for my particular remote gdb server it's running on ARM so i had to say target=arm-linux-gnuabi in configure. GDB is building for my PC x86 arch, but it knows when debugging to recognize the target as ARM!
Now, arm-linux-gnuabi-gdb is installed by default to /usr/local/bin ... but you can instead provide prefix=<path> to where you want it to install in ./configure script above.
Using this, I was able to build a secondary copy of gdb called arm-linux-gnuabi-gdb which i could feed to gdbgui like this:
gdbgui -g arm-linux-gnuabi-gdb
From there, I can give gdb commands to connect to my remote gdbserver. I'm having to set breakpoints beforehand. My gdb commands are like this to set a few breakpoints:
set breakpoint pending on
break my_object.cpp:<line number for breakpoint>
b example_function_name
target remote <remote arm machine IP>:<gdbserver port>
c
Works great! This is leaps and bounds better than running gdb on commandline on my remote target.
After I installed gdbserver on my remote machine (Ubuntu 16.04.4 LTS), I tested the following c++ code by making a "cross-platform console application (linux)" project in Visual Studio 2017:
#include <cstdio>
int main()
{
printf("hello from testLinuxDebug!\n");
return 0;
}
I added the connection information (ip address, id, password) of my Ubuntu machine to connection manager and selected "gdbserver" for debugging mode.
Then I started debugging and got the following message:
Unable to start debugging. Unexpected GDB output from command
"-interpreter-exec console "target remote localhost63361"". Remote
connection closed.
Message after starting to debugging (Image captured from VS2017)
By the way, I got the following message from the Linux Console Window of debug menu of Visual Studio 2017:
Process /home/.../projects/testLinuxDebug/bin/x64/Debug/testLinuxDebug.out
created; pid = 29277 Listening on port 4444 Remote debugging from host
127.0.0.1 /build/gdb-9un5Xp/gdb-7.11.1/gdb/gdbserver/regcache.c:264: A problem > internal to GDBserver has been detected. Unknown register ymm0h requested
Message from Linux Console Window (Image captured from VS2017)
Could anybody help me with this problem?
I was having this exact same problem on my Ubuntu 16.04 machine.
I went through the source code on gdbserver, and it appears to be a problem with a processor register (ymm0h) which is only available to i386 processors.
The thing is, I don't know how to fix gdbserver to not use this register in particular, but you can solve the error by upgrading your gdb & gdbserver to version 8.3 on the Ubuntu machine. If my guess is correct, version 8.1 was the one that fixed this issue, but by default, Ubuntu 16.04 has version 7.11.1 for both gdb & gdbserver.
You can run these commands on the linux machine to do that:
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
./configure --prefix=/usr --with-system-readline
make
sudo make install
You may need to install some extra packages in order to compile the gdb:
sudo apt-get install libreadline6-dev texinfo
If you still have problems trying to install gdb, try this example from Linux from Scratch.
Good luck!
I encountered the same problem as you, although for me the issue was on Microsoft's Visual Studio Online platform - I couldn't use pwntools' gdb.debug/gdb.attach functionality (that relies on gdbserver) due to this very same error in VSOnline's docker environment.
Leaving this answer here for people who might encounter the same issues that I have.
The issue and the steps are pretty similar to what Canella described - the root of the problem is indeed the old GDB version in the environment (7.12 at the time of writing).
I've compiled my GDB with python3 bindings, and you might want to do that too if you're planning to use GEF or similar GDB extensions.
Here's how to do that in your VSOnline environment's terminal:
# I needed to get rid of the apt-provided gdb for it to work properly
sudo apt remove gdb
# VSOnline has a weird way of handling python versions
# you're better off installing python3 from apt, if it's not installed yet
sudo apt update
sudo apt install libreadline6-dev texinfo python3 python3-dev
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
mkdir build && cd build
../configure --prefix=/usr --with-system-readline --with-python=/usr/bin/python3
make
sudo make install
I am using debian 9.4, the kernel version shown by uname -a is different, what's the actual kernel version? What does '4.9.82-1+deb9u3' mean?
Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux
apt-get source linux can get the source code of current kernel, then I can get original kernel tar file and debian patch.
$ls
linux-4.9.82 linux_4.9.82-1+deb9u3.dsc
linux_4.9.82-1+deb9u3.debian.tar.xz linux_4.9.82.orig.tar.xz
linux_4.9.82-1+deb9u3.debian.tar.xz contains many files, what are them used for? how to patch the it to linux_4.9.82.orig.tar.xz ?
linux-4.9.82 is the kernel source folder outputted by apt-get source command, which can be compiled to vmlinux. However, I usually can't debug the crash dump files with the vmlinux, as 'crash' command gives the error message: mismatch version. Should I download kernel 4.9.0 from kernel.org instead of linux-4.9.82 to debug my current running kernel ?
You have the package version. The name is made by:
4.9.82: the upstream version
-1: separator and Debian version of 4.9.82 upstream package. Note: if Debian is also upstream of a package, this field is skipped.
+deb9u3: this is a sort of micro-version. The +deb is used for security advisories, so minimal changes compared with 4.9.82-1. The 9 is the Debian version, and u3 is the third security version.
But kernels are different (compared with most of other packages): one could install many in parallel (but it will use only one). So in the package name you may have linux-image-4.9.0-3-amd64. In my system this package has version 4.9.30-2+deb9u1. So 4.9 is the kernel version. -amd64 is the architecture, this is the third major Debian version (-3) of 4.9(.0) series, which is based on 4.9.30.
the command uname will give you the kernel (as package name, so near the capability) in the field kernel-release and the package version (so exact reference to source) in the field kernel-version).
For the main question: I would use original kernel, and compile with upstream method (if I think the bug is kernel related, so it is easier to discuss with kernel maintainers), or I would use Debian sources (e.v. with patch), and build the kernel with Debian tools (and install the package to install the kernel), if I think the problem is in Debian, or just on old kernel versions.
Currently running Ubuntu 14.04 x86_64. I want to cross compile rethinkdb for my RPi for experimental purposes, which is supported in 1.12 (and people have apparently successfully compiled).
I have installed the toolchain:
sudo apt-get install g++-4.7-arm-linux-gnueabi gcc-arm-linux-gnueabi
export CXX=/usr/bin/arm-linux-gnueabi-g++-4.7
export CC=/usr/bin/arm-linux-gnueabi-gcc-4.7
export AR=/usr/bin/arm-linux-gnueabi-ar
export LD=/usr/bin/arm-linux-gnueabi-ld
Configuration runs:
./configure --ccache --allow-fetch --without-tcmalloc
* Detecting system configuration
Bash: 4.3.8(1)-release
Use ccache: yes
C++ Compiler: GCC 4.7 (/usr/bin/arm-linux-gnueabi-g++-4.7)
Host System: arm-linux-gnueabi
Build System: Linux 3.13.0-24-generic x86_64
Cross-compiling: yes
Host Operating System: Linux
Without tcmalloc: yes
Build client drivers: no
Build Architecture: x86_64
Precompiled web assets: no
Protobuf compiler: /usr/bin/protoc
Node.js package manager: /usr/bin/npm
LESS css: external/less_1.6.2
CoffeeScript: external/coffee-script_1.7.1
Handlebars: external/handlebars_1.3.0
Browserify: external/browserify_3.24.13
ProtoBuf.js: external/protobufjs_2.0.4
wget: /usr/bin/wget
curl: /usr/bin/curl
protobuf: external/protobuf_2.5.0
v8: external/v8_3.22.24.17
RE2: external/re2_20140111
z: external/zlib_1.2.8
Google Test: external/gtest_1.6.0
termcap: no
Test protobuf: external/protobuf_2.5.0
Test boost: external/boost_1.55.0
Installation prefix: /usr/local
Configuration prefix: /usr/local/etc
Runtime data prefix: /usr/local/var
* Warning: ARM support is still experimental
* Wrote configuration to config.mk
However make fails,
/bin/bash: ccache: command not found
Any pointers to getting this working?
Any pointers to getting this working?
Just install ccache. It would be helpful even if you did not have this issue because it somewhat speeds the compilation up on embedded. We are also using it at the company, fwiw, even with icecream, eventually.
sudo apt-get install ccache
The actual state of cross compiling rethinkdb for raspberry-pi is complicated right now. It seems that this is not actively maintained and it became complicated to set it up over the years. This is however possible with a little bit of effort. It requires dwelving into the rethinkdb build framework based on good ol' makefiles...
You can find an attempt at doing so here in a Dockerfile. It basically creates a Docker container with all the dependencies (especially the cross compiler), modify the config and build rethinkdb. The outcome is the rethinkdb package for raspberry.
You can either use it as is or have a look to it and reproduce it on your own.