Systemtap does not find the tapping points - linux-kernel

I was trying to compile my own kernel through clang-13 and run systemtap on that. I have enabled the CONFIG_DEBUG_INFO, CONFIG_DEBUG_KERNEL and all other default debugging configs including CONFIG_KPROBES, CONFIG_UPROBES. Additionally I have disabled CONFIG_RANDOMIZE_BASE. To compile and install I ran make -j8 bindeb-pkg && sudo dpkg -i ../*.deb. As you can see from the screenshot below the dbg package was installed and the sha256 confirms that the vmlinux matches, so systemtap should have access to its symbols. However, that doesn't seem to be the case since systemtap fails.
Additionally I compile the latest systemtap with clang-13 as follows make -j8 CC=clang-13 CXX=clang++-13 CFLAGS="-Wno-error" CXXFLAGS="-Wno-error".
The systemtap version is 4.7/0.170 and it says tested kernel versions: 2.6.32 ... 5.15.0-rc7. I might be missing something here.

Tracepoints in stap are identified by chewing through kernel headers (and sometimes sources). You can check whether stap is finding them with greater verbosity, such as:
stap -k -p2 --poison-cache --vp 04 -e 'probe ....'
If it's working, you'll see a lot of compiler invocations related to "tracequery", and you can see the residue of the searches under $TMPDIR (due to the -k option).

Related

/lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.34' [duplicate]

I'm very new to Yesod and I'm having trouble building Yesod statically
so I can deploy to Heroku.
I have changed the default .cabal file to reflect static compilation
if flag(production)
cpp-options: -DPRODUCTION
ghc-options: -Wall -threaded -O2 -static -optl-static
else
ghc-options: -Wall -threaded -O0
And it no longer builds. I get a whole bunch of warnings and then a
slew of undefined references like this:
Linking dist/build/personal-website/personal-website ...
/usr/lib/ghc-7.0.3/libHSrts_thr.a(Linker.thr_o): In function
`internal_dlopen':
Linker.c:(.text+0x407): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/unix-2.4.2.0/libHSunix-2.4.2.0.a(HsUnix.o): In
function `__hsunix_getpwent':
HsUnix.c:(.text+0xa1): warning: Using 'getpwent' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/unix-2.4.2.0/libHSunix-2.4.2.0.a(HsUnix.o): In
function `__hsunix_getpwnam_r':
HsUnix.c:(.text+0xb1): warning: Using 'getpwnam_r' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/libpq.a(thread.o): In function `pqGetpwuid':
(.text+0x15): warning: Using 'getpwuid_r' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/libpq.a(ip.o): In function `pg_getaddrinfo_all':
(.text+0x31): warning: Using 'getaddrinfo' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__63.o): In function `sD3z_info':
(.text+0xe4): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__164.o): In function `sFKc_info':
(.text+0x12d): warning: Using 'getprotobyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__155.o): In function `sFDs_info':
(.text+0x4c): warning: Using 'getservbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/libpq.a(fe-misc.o): In function `pqSocketCheck':
(.text+0xa2d): undefined reference to `SSL_pending'
/usr/lib/libpq.a(fe-secure.o): In function `SSLerrmessage':
(.text+0x31): undefined reference to `ERR_get_error'
/usr/lib/libpq.a(fe-secure.o): In function `SSLerrmessage':
(.text+0x41): undefined reference to `ERR_reason_error_string'
/usr/lib/libpq.a(fe-secure.o): In function `initialize_SSL':
(.text+0x2f8): undefined reference to `SSL_check_private_key'
/usr/lib/libpq.a(fe-secure.o): In function `initialize_SSL':
(.text+0x3c0): undefined reference to `SSL_CTX_load_verify_locations'
(... snip ...)
If I just compile with just -static and without -optl-static
everything builds fine but the application crashes when it tries to
start on Heroku.
2011-12-28T01:20:51+00:00 heroku[web.1]: Starting process with command
`./dist/build/personal-website/personal-website -p 41083`
2011-12-28T01:20:51+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: error while loading shared libraries: libgmp.so.10:
cannot open shared object file: No such file or directory
2011-12-28T01:20:52+00:00 heroku[web.1]: State changed from starting
to crashed
I tried adding libgmp.so.10 to the LD_LIBRARY_PATH as suggested in here
and then got the following error:
2011-12-28T01:31:23+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: /lib/libc.so.6: version `GLIBC_2.14' not found
(required by ./dist/build/personal-website/personal-website)
2011-12-28T01:31:23+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: /lib/libc.so.6: version `GLIBC_2.14' not found
(required by /app/dist/build/personal-website/libgmp.so.10)
2011-12-28T01:31:25+00:00 heroku[web.1]: State changed from starting
to crashed
2011-12-28T01:31:25+00:00 heroku[web.1]: Process exited
It seems that the version of libc that I'm compiling against is
different. I tried also adding libc to the batch of libraries the
same way I did for libgmp but this results in a segmentation fault
when the application starts on the Heroku side.
Everything works fine on my PC. I'm running 64bit archlinux with ghc
7.0.3. The blog post on the official Yesod blog looked pretty easy
but I'm stumped at this point. Anyone have any ideas? If there's a way to get this thing working without building statically I'm open to that too.
EDIT
Per Employed Russians answer I did the following to fix this.
First created a new directory lib under the project directory and copied the missing shared libraries into it. You can get this information by running ldd path/to/executable and heroku run ldd path/to/executable and comparing the output.
I then did heroku config:add LD_LIBRARY_PATH=./lib so when the application is started the dynamic linker will look for libraries in the new lib directory.
Finally I created an ubuntu 11.10 virtual machine and built and deployed to Heroku from there, this has an old enough glibc that it works on the Heroku host.
Edit:
I've since written a tutorial on the Yesod wiki
I have no idea what Yesod is, but I know exactly what each of your other errors means.
First, you should not try to link statically. The warning you get is exactly right: if you link statically, and use one of the routines for which you are getting the warning, then you must arrange to run on a system with exactly the same version of libc.so.6 as the one you used at build time.
Contrary to popular belief, static linking produces less, not more, portable executables on Linux.
Your other (static) link errors are caused by missing libopenssl.a at link time.
But let's assume that you are going to go the "sane" route, and use dynamic linking.
For dynamic linking, Linux (and most other UNIXes) support backward compatibility: an old binary continues to work on newer systems. But they don't support forward compatibility (a binary built on a newer system will generally not run on an older one).
But that's what you are trying to do: you built on a system with glibc-2.14 (or newer), and you are running on a system with glibc-2.13 (or older).
The other thing you need to know is that glibc is composed of some 200+ binaries that must all match exactly. Two key binaries are /lib/ld-linux.so and /lib/libc.so.6 (but there are many more: libpthread.so.0, libnsl.so.1, etc. etc). If some of these binaries came from different versions of glibc, you usually get a crash. And that is exactly what you got, when you tried to place your glibc-2.14 libc.so.6 on the LD_LIBRARY_PATH -- it no longer matches the system /lib/ld-linux.
So what are the solutions? There are several possibilities (in increasing difficulty):
You could copy ld-2.14.so (the target of /lib/ld-linux symlink) to the target system, and invoke it explicitly:
/path/to/ld-2.14.so --library-path <whatever> /path/to/your/executable
This generally works, but can confuse an application that looks at argv[0], and breaks for applications that re-exec themselves.
You could build on an older system.
You could use appgcc (this option has disappeared, see this for description of what it used to be).
You could set up a chroot environment matching the target system, and build inside that chroot.
You could build yourself a Linux-to-olderLinux crosscompiler
You have several issues.
You should not build production binaries on bleeding edge distributions. The libraries on the production system will not be forward compatible.
You should not link glibc statically - it will always at runtime try to load additional libraries. For example cpu-based assembly. That is what your first warnings are about.
The last linker errors look like they are related to a missing openssl library on the command line.
But all in all - downgrade your distribution.
I had similar problems launching to Heroku (which uses glibc-2.11) where I had an application that required glibc-2.14, but I did not have access to the source and could not re-build it. I tried many things and nothing worked.
My workaround was to launch the service on Amazon Elastic Beanstalk and just provide an API interface.
I found the information provided useful as well, I think the various descriptions miss a critical issue I also ran into while forcing an updated version of Vagrant to start working again.
It's the dependency references internal to something like complicated installs, like Yesod to Heroku. Those interanl refences need to be preserved.
This is the script I wrote to make problems go away (at least, hopefully, for a little while):
#!/bin/bash
cd $HOME/
GLIBC_VERSION="2.17"
GLIBC_PREFIX="/usr/glibc/"
VAGRANT_VERSION="2.2.19"
# Install the basic build system utilities.
yum groupinstall -y "Development tools"
yum install -y curl patchelf
# Grab the tarball with the GNU libc source code.
curl -Lfo glibc-${GLIBC_VERSION}.tar.gz "https://ftp.gnu.org/gnu/glibc/glibc-${GLIBC_VERSION}.tar.gz"
echo "a3b2086d5414e602b4b3d5a8792213feb3be664ffc1efe783a829818d3fca37a glibc-${GLIBC_VERSION}.tar.gz" | sha256sum -c || exit 1
# Extract the secrets and get ready to rumble.
tar xzvf glibc-${GLIBC_VERSION}.tar.gz
# The configure script requrires an independent build directory.
mkdir -p glibc-build && cd glibc-build
# Configure glibc with a GLIBC_PREFIX so it doesn't conflict with distro libc files..
../glibc-${GLIBC_VERSION}/configure --prefix="${GLIBC_PREFIX}" --libdir="${GLIBC_PREFIX}/lib" \
--libexecdir="${GLIBC_PREFIX}/lib" --enable-multi-arch
# Compile and then install GNU libc.
make -j8 && make install
# Download and install Vagrant.
curl -Lfo vagrant_${VAGRANT_VERSION}_x86_64.rpm "https://releases.hashicorp.com/vagrant/${VAGRANT_VERSION}/vagrant_${VAGRANT_VERSION}_x86_64.rpm"
echo "990e8d2159032915f21c0f1ccdcbca1a394f7937e06e43dc1dabe605d208dc20 vagrant_${VAGRANT_VERSION}_x86_64.rpm" | sha256sum -c || exit 1
yum install -y vagrant_${VAGRANT_VERSION}_x86_64.rpm
# Patch the binaries and shared libraries inside the Vagrant directory, so they use the new version of GNU libc.
(find /opt/vagrant/ -type f -exec file {} \; )| grep "dynamically linked" | awk -F':' '{print $1}' | while read FILE ; do
patchelf --set-rpath /opt/vagrant/embedded/lib:/opt/vagrant/embedded/lib64:/usr/glibc/lib:/usr/lib64:/lib64:/lib --set-interpreter /usr/glibc/lib/ld-linux-x86-64.so.2 "${FILE}"
done
The script should be pretty easy to understand, and adapt easily to whatever MacGuffin you want to make work, provied you understand it.
The only tricky part is the rpath you pass to patchelf. Upi need to make sure you preserve the search paths, and precedence your software requires. Or you end up fixing one problem only to create another equally frustrating roadblock.
P.S. Don't forget the update the hashes for any file you down. In particular, you need to compile/install a different version of GNU libc, you will need to update that hash to match the version you want to use.

How to dynamically link your nim-application against musl?

I've written a web-server in nim using the prologue framework. I would like to deploy that application using an alpine-docker-container.
As far as I'm aware, compiling means you dynamically link against your system libraries for whatever you need, that system library on any normal distro being glibc.
On alpine however you do not use glibc, you use musl, so dynamically linking against glibc means my application will expect glibc functions with glibc names that do not exist since there are only musl functions.
The big question that arises out of this for me as a python developer that jumped onto nim and knows very little about compilers:
How do I compile, so that I link dynamically against musl?
The folks from nim discord's brought me to the answer. It consists of passing flags to the nim-compiler to swap out the compiler nim normally uses for its generated C-code, in order to use musl-gcc. This can be done by using the --gcc.exe:"musl-gcc" and --gcc.linkerexe:"musl-gcc" flags.
Here an example for Linux:
1. install musl to get access to musl-gcc
download the tar file from the official musl page
Unpack the tar file somewhere
Run bash configure in the unpacked directory. WARNING: Make sure that you do NOT install musl with --prefix being /usr/local, as that may adversely affect your system. Use somewhere else where it is unlikely to override files, e.g. /usr/local/musl. This path will further be referred to as <MUSL_INSTALL_PATH>
Run make && make install in the unpacked directory
Add <MUSL_INSTALL_PATH> to your PATH environment variable
Validate whether you set everything up correctly by opening a new terminal and seeing whether you have access to the musl-gcc command
2. Compile with musl
Create a compile command with --gcc.exe:"musl-gcc" to swap out gcc with musl-gcc and --gcc.linkerexe:"musl-gcc" to swap out the default linker with musl-gcc as well. An example can look like this:
nim c \
--gcc.exe:"musl-gcc" \
--gcc.linkerexe:"musl-gcc" \
--define:release \
--threads:on \
--mm:orc \
--deepcopy:on \
--define:lto \
--outdir:"." \
<PATH_TO_YOUR_MAIN_PROJECT_FILE>.nim
run the command
This should generate a binary that is dynamically linked against musl and thus can run within an alpine docker container.

How to cross compile GCC on x86 for Sun4v?

I am writing a programming assignment using C++. The instructor of this course requires all code to be compiled and run on the UNIX server. The server is a SunOS machine. I wrote all my code on my personal laptop with GCC 5.2, which support most C++11 features. However, when I upload my code to the server and tried to compile it, I surprisingly found that the g++ version on the server is 4.2.1, which was released in mid-2007. Many of the C++11 features are not supported. Even the -std argument is not accepted.
I tried to download the source code of the latest GCC and compile it on the server. Unfortunately there is a disk quota limiting to 500M per account. I am just wondering if it is possible to cross compile GCC on my x86 machine and upload the binary on to the server so that I can compile my C++ code.
By the way, I have contacted the IT department about updating the software but they responded that they do not have such plans in the near future.
I did do research on the Internet about cross compilation and found a couple tutorials. But they are not easy to follow. In addition to binaries, there are also a lot dependencies like headers and libraries. So before I give up and modify my code to fit the old compiler, can anyone give me some suggestions?
Thank you.
uname -a returns the following result
SunOS 5.10 Generic_147147-26 sun4v sparc SUNW,T5240
Of course it's possible, and it's the way you usually do the things when writing operating systems.
First of all, you need to take binutils in the toolbox, too. Once you have all the Holy Sources, let's prepare!
export PREFIX="$HOME/opt" # All the stuff will get installed here!
export TARGET=sparc-sun-solaris # I'm not *100%* sure if this is correct, check it yourself
export PATH="$PREFIX/bin:$PATH" # If you forget this/close the terminal, you're doomed!
Now, let's get with the little monster... Shall binutils be built!
cd $HOME/src # Or where you have the sources
mkdir binutils-build
cd binutils-build
../binutils-src/configure --target=$TARGET --prefix="$PREFIX" --disable-nls
make
make install
--disable-nls disables the support for native natural languages (a.k.a: the compiler prints errors in your own language!), and just uses English for messages. That's not a must, but it certainly speeds up the process of building binutils.
Now, compiling GCC itself is a very fragile process, and it can fail anywhere, anyhow, so be prepared! This process is long (it can take up to an hour on some machines), but trust me, LLVM+Clang is worse ;).
cd $HOME/src
cd gcc-src
./contrib/download_prerequisites # Get GMP, MPFR, and MPC
cd ..
mkdir gcc-build
cd gcc-build
../gcc-src/configure --target=$TARGET --prefix="$PREFIX" --disable-nls --enable-languages=c,c++
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
If you don't get into issues while compiling (trust me, you will unless you're too lucky for this world), you'll have a toolchain that runs on your machine, but compiles for SunOS/SPARC! BTW, --enable-languages=c,c++ means that GCC will have support for compiling C and C++ code. Nothing less, nothing more. Try it out with...
sparc-sun-solaris-g++ --version
Now, if you want to get a compiler for the server, that runs on the server, you will have to some mess with a double canadian cross. Basically, what you have to do is...
export PREFIX="$HOME/some-holy-directory" # This path *must* be the same for both your machine and the target server!
export HOST=$TARGET
And then repeat the compilation process again, remembering to adding the option --host=$HOST to both configure scripts! Once done, you must move that some-holy-directory at exactly the same location into the server. If it didn't fit into the 500MB, well, ask your teacher if you can at least compile assignments in your own machine, then upload them to the server. Otherwise, you're left out with C++98.
BTW: Please note that cross-compiling GCC itself is an even more fragile process. All this post is just theoretical, because I won't do all this steps just for the sake of doing it. Please comment if you have any major issues, or if someone spots an error in the steps ;).
Edit: Apparently, you'll have to build Glibc and all that funky stuff too...
I hope this has led some light on you!

gdb ARM Cortex-M exception Unwinding

I have been working with some Cortex-M4 (Freescale K60) devices with a compiled by me GCC (v4.7.2), BinUtils (v2.22), Newlib (v1.20) and GDB (v7.5). I have always been annoyed by GDB's inability to unwind from hard exceptions.
recently I had an opportunity to use FreeScale's CodeWarrior, where I loaded my binary for debug (compiled by my tools), and it could unwind the exception. It looks like CodeWarrior is running GDB v7.4.1 under the hood. Is there some patch I missed for GDB, or some configure option?
Here is the script used to build GDB:
TOOLCHAIN=gdb-7.5
mkdir -p BUILD/gdb
cd BUILD/gdb
../../${TOOLCHAIN}/configure --prefix=${PREFIX} --target=${TARGET} --enable-interwork --enable-multilib --with-expat=yes --with-python --without-auto-load-safe-path 2>&1 | tee configure.out
make all install
cd ../../
Thanks!
GDB can do Cortex M profile exception unwinding, once you tell it that the target is actually Cortex M profile using a Target Description XML with correct Feature.
This can be done via the set target tdesc <filename> command, but newer gdb servers (e.g. OpenOCD) should do so already.

How to build boost with mpi support on homebrew?

According to this post (https://github.com/mxcl/homebrew/pull/2953), the flag "--with-mpi" should enable boost_mpi build support for the related homebrew formula, so I am trying to install boost via homebrew like this:
brew install boost --with-mpi
However, the actual boost mpi library is not being build and can not be found.
There is currently some work being done around this, according to: https://github.com/mxcl/homebrew/pull/15689
In summary, I can currently build boost, but it seems the "--with-mpi" flag is being ignored. Could someone please check, if I should be able to build boost (with mpi support) on Mac OS X Mountain Lion (10.8)?
The (verbose) output generates these lines:
MPI auto-detection failed: unknown wrapper compiler mpic++
Please report this error to the Boost mailing list: http://www.boost.org
You will need to manually configure MPI support.
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
Not sure how exactly I can fix this and get the mpi stuff to be build - any ideas?
Just in case this helps anyone else along the line, here's how I fixed this. The main error is MPI auto-detection failed: unknown wrapper compiler mpic++, any typing mpic++ at the command line verified that it was not working properly for me. I used brew to install open-mpi, but the same error was showing in the verbose output for installing boost. A run of brew doctor showed that openmpi was not linked properly, so I fixed those errors and reran brew -v install boost --with-mpi --without-single and it finally built and installed all of the libraries without a problem
To anyone that comes across this, the package migrated to boost-python and boost-mpi separate from boost. Use brew install boost-mpi
Just get it worked on OSX 10.11.5. I've tried brew, but with no luck.
Suppose you already have gcc installed. Here are what I've done:
1. Find and disable (but do not remove) clang
clang alway cause headaches. There would be a lot of warnings when building Boost.
which clang, which should give you /usr/bin/clang
Rename it: sudo mv clang clang_mac_remove, also for clang++: sudo mv clang++ clang++_mac_remove. You can change the names back if you need them in future.
2. Install OpenMPI
If you already installed using brew, uninstall first. Becasue it would have used clang as the compiler wrapper by default. You need to change the wrapper to gcc.
Download the package.
Specify the wrapper compiler to gcc and g++:
./configure CC=gcc CXX=g++ F77=ifort FC=ifort --prefix=/usr/local
Below may take a long time.
make all
sudo make install
Reference: https://wiki.helsinki.fi/display/HUGG/Open+MPI+install+on+Mac+OS+X
3. Install Boost MPI
Download the package.
Run ./bootstrap.sh (can open it first and specify the toolset to gcc, otherwise, the default option is darwin for mac).
Add using mpi ; in project-config.jam file. Then ./b2 —with-mpi will only build the mpi library.
Then, all built libraries can be found in the folder ~/Downloads/boost_1_61_0/stage/lib.
Copy or move them to /usr/local/lib or any other commonly used library path.
Reference: http://www.boost.org/doc/libs/1_61_0/doc/html/mpi/getting_started.html
4. Compile with Boost MPI
LIBRARY DIR = -L/usr/local/lib
INCLUDE = -I/usr/local/include/
LINKER = -lboost_mpi -lboost_serialization
e.g.
mpic++ -std=c++11 -I/usr/local/include/ -c boost_test.cpp -L/usr/local/lib -lboost_mpi -lboost_serialization
Good luck!

Resources