How detect whether running under valgrind in make file or shell script? - valgrind

I need to detect whether my Makefile is running under valgrind (indirectly, using valgrind --trace-children=yes), I know how to do it from C but I have not found a way to do it from a script,
The earlier answers works on Linux only. For Mac OS X I am an going to grep for VALGRIND_STARTUP_PWD in the environment, unless someone has a better idea.

from a shell:
grep -q '/valgrind' /proc/$$/maps && echo "valgrindage"
This determines if the valgrind preloaded libraries are present in address map of the process. This is reasonably effective, but if you happen to have a non-valgrind related library that shares the '/valgrind' moniker then you will get a false positive (unlikely).
[I changed the grep pattern from vg_preload to /valgrind, as testing on Debian/Ubuntu revealed that the library name was different, while a directory match of valgrind is most likely to succeed.]

Related

What is the entry point for WSL 1?

Imagine we have a statically linked Linux executable.
How should I name it in the imported tar.gz so the WSL 1 will run it by default, when created and started like:
# import an archive as a WSL distro
wsl --import static tmp-root-dir static.tar.gz
# boot distro to a default app??
wsl -d static
PS WSL uses own proprietary boot process and seems doesn't use traditional Unix /sbin/init.
Short answer:
The smallest bootable (without errors or warnings) WSL rootfs will consist of three files:
/main: Your statically-linked application. It can be named whatever you want, as long as the name matches what is in passwd.
/etc/passwd: Defines the application (i.e. shell) to load for the default user.
/etc/wsl.conf: To suppress normal WSL functionality and (optionally) define the non-root user.
More detail:
This probably isn't exactly what you are wanting, but it will hopefully meet your needs.
To start with, the entry point for WSL (the first time a Linux ELF binary is started inside the instance) seems to be its /init binary, which, in addition to some "normal" Linux init process tasks, sets up some of the Windows-interop functionality. To my knowledge, it cannot currently be changed. As far as I can tell, for WSL1, it is injected into the instance by the LXSS manager when starting a WSL instance.
Note: WSL2 might be slightly different in this regard, as it does seem to use a kernel-processed initrd to load /init. It is possible to override the kernel command-line, but that would impact all WSL2 instances, so it's probably not a practical solution.
It's not quite clear from your question whether you want the "default application" to:
Run as the default application/shell every time wsl -d static is run, even if it was already running.
Or just run once when starting the WSL1 instance for the first time.
I believe you are looking for the first option.
Run as the default application
In the first case, the standard WSL1 /init process might get you to where you need to be. As part of the startup, as you would expect, it reads /etc/passwd to determine the user shell to start. It also reads /etc/wsl.conf to determine the default user ID (but falls back to the registry if there is no default user set in wsl.conf).
So, to start a different application (let's call it main), you can:
Place the binary in the root directory of your image.
Set the application as the "shell" of the root user in a single-line /etc/passwd:
user:x:1000:1000:user:/:/main
Side-note that this also sets the home directory to / so we don't have to create another directory.
Define a etc/wsl.conf with the following contents:
[user]
default=user
[automount]
enabled=false
mountFsTab=false
[interop]
appendWindowsPath=false
This will prevent WSL from performing the following startup tasks, which would produce an error without additional image support:
Mounting Windows drives into the instance
Attempting to process /etc/fstab (since we have no mount command in the image).
Appending Windows paths (since our instance won't have access to the Windows drives)
It also sets the default user to the UID 1000 user we created in /etc/passwd. This isn't strictly necessary - There's likely no concern with running as root in this single-use instance, but I've included a non-root user as a "best practice".
That should be it. The smallest bootable WSL rootfs will consist of just those three files:
/etc/wsl.conf
/etc/passwd
/main
This will work on WSL1 as well as WSL2, although for WSL2, you should invoke with wsl ~ -d static to make sure that it doesn't try to start on a Windows drive that it can't access. Otherwise, you'll receive an init error, but your application will still be invoked.
Run once
If you are looking for something that will, for instance, start up a daemon when the instance is started for the first time, then there are a few alternatives that I document in this answer. If you are on Windows 11, then there's a built-in mechanism via /etc/wsl.conf. Otherwise, on Windows 10, you'll probably need to include some binary that can handle conditional logic. Something like execline would probably be perfect for this, but I've had issues with it under WSL2, at least, and I'm not sure that it would run under WSL1 (but it might).
Side-note for WSL1/musl
musl is a commonly used alternative libc implementation. For instance, Rust (AFAICT), can only generate truly statically-linked executables using musl. Note, however, that WSL1 cannot run musl-based statically linked binaries.
WSL2 can handle them just fine.
I managed to get it working. Initially I missed an executable bit on the app when created TAR archive.
Take standard 64-bit assembly:
.data
msg:
.ascii "Hello, world!\n"
.set len, . - msg
.text
.globl _start
_start:
# write
mov $1, %rax
mov $1, %rdi
mov $msg, %rsi
mov $len, %rdx
syscall
# exit
mov $60, %rax
xor %rdi, %rdi
syscall
and create a minimal WSL system:
wsl as -64 -o minimal.o minimal.s
wsl ld -melf_x86_64 -o minimal minimal.o
tar czf minimal.tar.gz \
--mode=a=rx \
--xform='s#^minimal#/\0#' minimal
wsl --import minimal rootfs-minimal minimal.tar.gz --version 1
wsl --list
wsl -d minimal -e /minimal
To make executable default (shorten wsl -d minimal -e /minimal to wsl -d minimal) we need an extra file /etc/passwd:
root:x:0:0:root:/root:/minimal
First line of this file determine a default user and so path to the executable (entry point) unless you override the user with /etc/wsl.conf:
[user]
default=user
Basically WSL 1 treats only 2 files as magical (in addition to ignoring /sbin/init):
/etc/wsl.conf
/etc/passwd

Building a kernel module on Centos 7 with a CMake file

Sorry for the length. I have tried to include as much information as possible.
A device I work with randomly fails to start at boot - this is a well known issue with the device and there are lots of posts on the web with no known solution except reboot.
So the task is to look in dmesg for a certain string that if present means the device has failed to start and the system needs rebooting. A simple call to system() with boot seems to do the job.
A unit test that proves this would be nice. The idea is to look for a non-existant uuid in the dmesg log to prove that it fails to find one and then to write a different uuid to the log and then search for that. Proving it works in both cases.
First thing was to hit up google: Find you can write to the kernel log with # echo '<4>Foo: Message' | sudo tee /dev/kmsg which works from terminal but the sudo may cause issue in the unit test.
The next thing I looked at was accessing it via code. The unit tests are written in C++ and the library is googletest.
Most posts talk about writing a Makefile and kbuild. I am working in a build system where we have cmake called from a shell script.
After several hours of searching and trying things, I decided to ask here.
I have installed
kernel.x86_64 3.10.0-1062.el7 #anaconda
kernel.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-devel.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-devel.x86_64 3.10.0-1160.24.1.el7 #updates
kernel-headers.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-tools.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-tools-libs.x86_64 3.10.0-1160.21.1.el7
uname -r gives 3.10.0-1160.21.1.el7.x86_64 which seems to suggest I have the kernel headers and devel files installed.
Doing a find /. -name module.h lists:
...
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/arch/x86/include/asm/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/asm-generic/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/linux/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/trace/events/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/uapi/linux/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/arch/x86/include/asm/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/asm-generic/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/trace/events/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/uapi/linux/module.h
...
It maybe that I am trying to link files in /3.10.0-1160.24.1.el7.x86_64/ when I should be linking to 3.10.0-1160.21.1.el7.x86_64/. Listing installed yum packages via sudo yum list | grep linux-d returns
libselinux-devel.x86_64 2.5-15.el7 #base
libhbalinux-devel.i686 1.0.17-2.el7 base
libhbalinux-devel.x86_64 1.0.17-2.el7 base
libselinux-devel.i686 2.5-15.el7 base
syslinux-devel.x86_64 4.05-15.el7 base
My CMakeFiles.txt looks like
project( X_test )
set( TEST_SOURCE
X_test.cpp
)
execute_process(COMMAND uname -r OUTPUT_VARIABLE uname_r OUTPUT_STRIP_TRAILING_WHITESPACE)
include_directories(/usr/src/kernels/${uname_r}/include)
link_directories(/lib/modules/${uname_r}/build)
add_library(source-lib STATIC source.c)
Anything else in there has been commented out to prevent confusion.
Without the lines include_directories or link_directories I get the error
#include <linux/module.h>
With those lines in I get the error:
In file included from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/kernel.h:6:0,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/cache.h:4,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/time.h:4,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/stat.h:18,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/module.h:10,
from /home/user/git/asdo/Services/DCO-3303/test/source.c:1:
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/linkage.h:7:25: fatal error: asm/linkage.h: No such file or directory
#include <asm/linkage.h>
The code I am compiling is the standard printk(KERN_INFO "Hello world\n"); which you can see here.
How do I go about compiling code that uses a kernel call through CMake?

Testing Linux kernel drivers

i am newbie to linux kernel and all, is there any way to check the entry points of linux kernel drivers from command line? say for leds-lp5523?
i have seen this document says we can run some sample LED patterns by running the echo commands by running
cd /sys/class/leds/lp5523:channel2/device echo "load" > engine3_mode echo "9d80400004ff05ff437f0000" > engine3_load echo "111111111" > engine3_leds echo "run" > engine3_mode
But i cant find this /sys/class/leds/lp5523:channel2/device directory in my Ubuntu x86-64 PC.
Can anyone help me on this.
Thanks in advance..
This file will not be created until you actually have an LP5523 connected. I doubt this is the case on your PC as this is an i2c chip.
Else, you found the correct documentation. You can usually find two different interfaces for drivers, either device files (usually found in /dev) that are using the usually syscalls (open, read, write, ioctl) or a sysfs interface (found in /sys), the documentation is then found in Documentation/ABI/.
The best way to find whch interface the driver is using is still to read the source code for that driver.

Merge multiple stdout/stderr into one stdout

I have a development stack with multiple processes running: web server, auto-testing, compilation in background etc. All of these are basic command line commands such as node app.js or lein midje :autotest.
Is it possible with one script to run all these processes in "background" and merge their outputs into one stdout (that is: to show it on the screen in terminal)?
One of the problem with easy bash solution that I found (using &) is that on Ctrl+C the background processes are obviously kept alive, which is not possible desirable.
I have tried adding trap 'kill $(jobs -pr)' SIGINT SIGTERM EXIT but this doesn't seem to work reliably on OS X - surprisingly the node processes get killed, but the java ones are still living after the script exits (via Ctrl+C).
I can use any scripting language. I would prefer pure bash or JS, but Python or Ruby are OK too.
I would also like the ANSI escape colouring to be preserved in the merged output.
You might use multitail utility. It not only allows you to tail log files, but also output of arbitrary CLI programs (lein run, lein midje :autotest, ...).
Example:
$ multitail --mergeall -cT ANSI -l "lein midje :autotest" -cT ANSI -l "lein ring server-headless"
Ctrl-C than kills all processes which are being tailed.
If you are OSX user you can install multitail using brew install multitail (assuming that you already have homebrew installed - if not, see http://mxcl.github.io/homebrew/)
In order to get more info about multitail configuration you might read man multitail. There are also usage examples at http://www.vanheusden.com/multitail/index.php

ios Symbolication Server side

How to symbolicate the ios crash report after uploading to server in a linux environment where iOS development tools and scripts will not be available. I know Apple uses atos and some other tools to map the hex addresses to symbol along with .dYSM file.
I can upload .dYSM file along with crash report to server. Refered QuincyKit, but they are doing symbolication locally. But other's like HockeyApp and Critterism are doing it remotely.
Pls recommend the possible ways to do it in server.
It is possible. You can take a look at https://github.com/facebook/atosl
I got it working under Linux. (Ubuntu Server) However, it takes some time to get it up and running.
Installing atosl
First, you need to install libdwarf-dev, dwarfdump, binutils-dev and libiberty-dev.
E.g. on Ubuntu:
$ sudo apt-get install libdwarf-dev dwarfdump binutils-dev libiberty-dev
Download or clone the atosl repo from GitHub:
$ git clone https://github.com/facebook/atosl.git
CD to the atosl dir
$ cd atosl
Create a local config config.mk.local which contains a flag with the location of your binutil apps. (in Ubuntu by default that's /usr/bin). If you're not sure, you can find out by executing cat /var/lib/dpkg/info/binutils.list | less and copy the path of the file objdump. E.g. if the entry is /usr/bin/objdump, your path is /usr/bin.
So in the end, your config.mk.local should look like this:
LDFLAGS += -L/usr/bin
Compile it:
$ make
Now you can start using it:
$ ./atosl --help
Symbolicating example
To show how atosl is used, I'll provide a simple example.
Now let's take a look at a line from the crash log:
13 ErrorApp 0x000ea294 0xe3000 + 29332
To symbolicate this, we will need the load address, and the runtime address.
In this example the runtime address is 0x000ea294, and the load address is 0xe3000.
Now we have everything we need:
$ ./atosl -o [YOUR_dSYM_FILE] -l [LOAD_ADDRESS] [RUNTIME_ADDRESS]
In this example:
$ ./atosl -o ErrorApp.app.dSYM/Contents/Resources/DWARF/ErrorApp -l 0xe3000 0x000ea294
Which returns the symbolicated line:
main (in ErrorApp) (main.m:16)
FYI
Your vmaddr, which usually is 0x00001000, you can find by looking at the segname __TEXT Mach-O load command of your binary. In my example, this happens to be different, namely 0x00004000
To find the address, we need to do some math.
The address is found by the following formula:
address = vmaddr + ( runtime_address - load_address )
In this example our address is:
0x00004000 + ( 0x000ea294 - 0xe3000 ) = 0xB294
I haven't played around with this that much yet, but for now it seems to give me the results I needed. Maybe it will work for you too.
You need to implement your own linux compatible versions of atos, otool and dwarfdump (at least the functionality needed for symbolication). The Apple tools are not open source and only run on Mac OS X.
None of the services provide a solution that can be used by 3rd parties on non OS X systems. So your only chance, besides implementing the required functionality to run on your linux system, is to do it on a Mac like QuincyKit does it, see https://github.com/TheRealKerni/QuincyKit/wiki/Remote-symbolication or use a third party service.
Note: I am the creator of QuincyKit and Co-Founder of HockeyApp.