Created attachment 10711 [details] kernel config Having this error on mipsel emulation: ... stapio:stp_main_loop:861 systemtap_module_init() returned 0 ERROR: Unknown register: a4 stapio:stp_main_loop:852 got STP_REQUEST_EXIT WARNING: Number of errors: 1, skipped probes: 0 stapio:stp_main_loop:841 got STP_EXIT stapio:cleanup_and_exit:526 detach=0 ... # stap --version Systemtap translator/driver (version 3.2/0.168, non-git sources) Copyright (C) 2005-2017 Red Hat, Inc. and others This is free software; see the source for copying conditions. tested kernel versions: 2.6.18 ... 4.11 enabled features: AVAHI LIBSQLITE3 NLS NSS # uname -a Linux arex-11f9b261f2 4.9.0-4-4kc-malta #1 Debian 4.9.65-3 (2017-12-03) mips GNU/Linux The Rootfs is a Debian Stretch. It seems to be an ABI (O32/N32) issue, but not sure why it's happening. I've locally compiled SystemTap from Systemtap 3.2 release (https://sourceware.org/systemtap/ftp/releases/systemtap-3.2.tar.gz) Any clue?
(In reply to Gustavo Moreira from comment #0) > Created attachment 10711 [details] > kernel config > > Having this error on mipsel emulation: > ... > stapio:stp_main_loop:861 systemtap_module_init() returned 0 > ERROR: Unknown register: a4 It looks like this is coming from tapset/mips/registers.stp. It appears that that file has only been tested against 64-bit kernels. It doesn't think the a4-a7 registers exist in a 32-bit kernel. That prevents it from grabbing the 5th through 8th argument to a function (in _stp_arg()). If you know the calling convention for a 32-bit mips kernel, we can fix that file.
It seems a4-a7 registers exist in n32 but not in o32. Debian uses o32, so it seems SystemTap struggles to detect the ABI or it just uses n32 by default. The kernel is a prebuilt one. I got it from (http://ftp.debian.org/debian/dists/stretch/main/installer-mipsel/current/images/malta/netboot/vmlinux-4.9.0-4-4kc-malta) I've extracted the .config file from kernel and I've attached it to this ticket.
Created attachment 10751 [details] Simple mips patch Here's a simple (untested) patch that will get you past your initial error message and allow you to access the first 4 arguments of a function. To access the rest, someone with knowledge of the 32-bit MIPS ABI (and access to MIPS hardware) will need to write some code that decodes the MIPS o32 user and kernel stacks.
I went ahead and checked in this patch as commit 1d0a3dc015c.
(In reply to David Smith from comment #3) > Created attachment 10751 [details] > Simple mips patch > > Here's a simple (untested) patch that will get you past your initial error > message and allow you to access the first 4 arguments of a function. To > access the rest, someone with knowledge of the 32-bit MIPS ABI (and access > to MIPS hardware) will need to write some code that decodes the MIPS o32 > user and kernel stacks. Actually, I've replaced the final FIXME assert() with error() instead, otherwise it raises another compilation error. Anyway, the assert() function executes error() so it should be equivalent: error(sprintf("Cannot access arg(%d)", argnum)) But yeah it would be needed to write some code to fix it completely.
(In reply to Gustavo Moreira from comment #5) > But yeah it would be needed to write some code to fix it completely. If you have the time to figure this out, go ahead and send us a patch. We'll be happy to review it and check it in for you.
Created attachment 10988 [details] MIPS o32 ABI patch This is based on arch/mips/include/ptrace.h and ARM registers.stp. However, it doesn't seem to be working correctly, the values extracted from the user stack, for some reason, aren't the correct ones. I would appreciate if you can review the patch and help me out.
Merged that patch (slightly adjusted). Sorry, I am not sure what to do with the userspace registers, though there should be a user-side pt_regs struct with a saved register dump available.
Don't have any access to MIPS machines, so it is unlikely that we will be able to address this further.