I'm trying to run the ManualExamples of the latest Pin tool from Intel (3.7-97619) on Kali 32-bit (Linux kali32 4.19.0-kali4-686-pae #1 SMP Debian 4.19.28-2kali1 (2019-03-18) i686 GNU/Linux).
I could compile the examples found in source/tools/ManualExamples using make TARGET=ia32, but as soon as I run an example with the command ../../../pin -t obj-ia32/isampling.so -- /bin/ls from the ManualExamples as suggested in the documentation. Nonetheless, I face the following issue:
A: Source/pin/elfio/img_elf.cpp: ProcessSectionHeaders: 560: assertion failed: SEC_vaddr_i(sec) >= IMG_seg_text_vaddr_i(img) && SEC_vaddr_i(sec) < IMG_seg_data_vaddr_i(img)
################################################################################
## STACK TRACE
################################################################################
??? at isampling.so+0x24472
??? at isampling.so+0x90946
??? at isampling.so+0x98671
??? at isampling.so+0x14654d
??? at isampling.so+0x148b9d
??? at isampling.so+0x148c50
??? at isampling.so+0x6f243
??? at isampling.so+0x4bfab
_ZN14LEVEL_INJECTOR13UNIX_INJECTEE12StartProgramEb+0x10f at /root/pin/ia32/bin/pinbin+0x3354af
??? at isampling.so+0x48889
main+0x97 at isampling.so+0x90d7
_ZN14LEVEL_INJECTOR13UNIX_INJECTEE9StartToolEv+0x1d2 at /root/pin/ia32/bin/pinbin+0x333f12
_ZN14LEVEL_INJECTOR13UNIX_INJECTEE29RunMainThreadOnPinStackAttachEPS0_+0x3de at /root/pin/ia32/bin/pinbin+0x3374ee
Pin: pin-3.7-97619-0d0c92f4f
Copyright (c) 2003-2018, Intel Corporation. All rights reserved.
Aborted
So, I decided to run pin without any tool using the command pin -- /bin/ls and it works. Any idea why I get this error message ?
Many thanks
After some hours lost in the investigation of this issue with a colleague, we could not figure out the reason of this error. We tried on Kali and Debian that were up to date.
Later on, I decided to try on a old Ubuntu virtual machine with the kernel 4.15.0-47-generic and it worked! More precisely:
➜ ~ uname -a
Linux gpu 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
➜ ~ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
I did not try on a newer version of Ubuntu, so I cannot state this is due to a new software component, such as a newer version of the kernel. My workaround is therefore to use an older version of the kernel, without having the certainty this is what caused the issue.
Any further investigation answer on this thread that would identify the issue better will be marked as the answer.
Related
I want to check the use of the pthread_mutex_lock function, so I execute the command man pthread_mutex_lock, the result appears No manual entry for pthread_mutex_lock.
I checked the information on the Internet and said that there was a No manual entry for pthread_mutex_lock prompt, need to install manpages-posix-dev.
So I'm ready to install manpages-posix-dev(I execute the command: apt-get install manpages-posix-dev), but E: Unable to locate package manpages-posix-dev prompts me again. Why?I'm using the debian 10 system.
gyz#debian:~$ man pthread_mutex_lock
No manual entry for pthread_mutex_lock
gyz#debian:~$ sudo apt-get install manpages-posix-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package manpages-posix-dev
gyz#debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
gyz#debian:~$ getconf LONG_BIT
64
gyz#debian:~$ cat /proc/version
Linux version 4.19.0-9-amd64 (debian-kernel#lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1
SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
(Even though the question is tagged Debian it appears in generic search results)
The answer for Fedora is that Fedora has removed posix manpages entirely; you need to download/install 'manually' (there's a make installer included in the archive) from https://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/
(Thanks to redditors)
Goal:: "Is to emulate imx6 Quad G4 device with QEMU or any other emulation software. I have got u-boot-mx6q-4g.bin and mon_imx_minikernel.bin files from the actual working device"
I m novice to emulation world. Honestly don't know where to start.
I believe QEMU supports "imx6 Quad 4G ram devices" with sabrelite board but qemu version installed on host machine Ubuntu 16.04 is missing sabrelite board, did try to install qemu-user-static but still no luck.
qemu-system-arm -M help
Supported machines list is missing sabrelite in my installation.
qemu-system-arm -version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.32), Copyright (c) 2003-2008 Fabrice Bellard
Currently my host machine is Ubuntu 16.04
$uname -a
Linux mike 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Any guidance is very much appreciated
apt upgrade qemu* has not upgraded the OS.
However Sabrelite and more machine options showed up after upgrading host OS to 18.04.
In process of upgrade it upgraded the QEMU also.
I'm going through a course on gdb. In the later lessons the course covers debugging on ARM architecture, so I'm presented a setup that allows me to emulate such situation.
My current setup comprises:
Windows 10: physical host
Ubuntu 12.04.5 LTS: guest os via Oracle Virtual Box on Windows 10
Linux debian-armel 2.6.32-5-versatile: guest os via qemu 2.8.0 on Ubuntu
The ARM Debian image comes from https://people.debian.org/~aurel32/qemu/armel/
The image is launched with
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -m 256 -redir tcp:2222::22
I modified the sources.list and apt.conf to allow apt to work, since the distro is quite outdated. I updated and upgraded and installed gcc and gdb.
The problem arises when trying to debug; I can load executables in gdb:
root#debian-armel:~/video-11/video-11# file ./main
./main: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
but when I try to run it inside gdb, I receive this message and the execution hangs, until I'm able to kill the gdb process from another console:
------------[ cut here ]------------
WARNING: at /build/linux-2.6-fIxTVd/linux-2.6-2.6.32/debian/build/source_armel_none/kernel/sched.c:2628 wake_up_process+0x2c/0x48()
Modules linked in: loop sg smc91x sr_mod mii cdrom psmouse evdev ext3 jbd mbcache sd_mod crc_t10dif sym53c8xx scsi_transport_spi scsi_mod
[<c002b068>] (unwind_backtrace+0x0/0xdc) from [<c0046f88>] (warn_slowpath_common+0x4c/0x80)
[<c0046f88>] (warn_slowpath_common+0x4c/0x80) from [<c00446f0>] (wake_up_process+0x2c/0x48)
[<c00446f0>] (wake_up_process+0x2c/0x48) from [<c0026930>] (arch_ptrace+0x214/0x4bc)
[<c0026930>] (arch_ptrace+0x214/0x4bc) from [<c00508d8>] (sys_ptrace+0x9c/0x164)
[<c00508d8>] (sys_ptrace+0x9c/0x164) from [<c0024ec0>] (ret_fast_syscall+0x0/0x28)
---[ end trace 98ab50bc781b314f ]---
How can I resolve this issue?
Not my answer, but to enable the question to be marked as closed:
This is likely a bug in the guest kernel (though not certainly so), so
I would start by trying with a more recent kernel than 2.6.32, which
is now nearly 8 years old. – Peter Maydell Mar 3 '17 at 13:14
I'm trying to build a simple kernel module and run it on the Raspberry Pi. I have downloaded kernel sources from official raspberry site, but they have slightly different kernel version then my raspbian on board.
Is it necessary to have fully identical version of kernel on source and target machine to run kernel module? I have this on my Raspberry Pi
$ uname -a
Linux raspberrypi 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux
And this about my module
$ modinfo ./threads.ko
filename: /lib/modules/4.4.11+/kernel/mymodules/./threads.ko
version: 0.0.1
description: Kernel threads example
author: xxxxxx
license: GPL
srcversion: C906582EC824D2D8DA76BFB
depends:
vermagic: 4.4.13+ mod_unload modversions ARMv6
As you see: "4.4.11+" vs "4.4.13+"...
Why am I asking? I have a error when insert module:
$ sudo insmod ./threads.ko
insmod: ERROR: could not insert module ./threads.ko: Invalid module format
And do not understand, it is valuable difference in last number of version of the kernel or there is another problem.
Is it necessary to have fully identical version of kernel on source and target machine to run kernel module?
Yes.
I am trying to get libcap to work on my machine (running Ubuntu 12.04) but I am currently unable to get this done:
Here is how it all began:
In Eclipse I got the warning that it could not resolve pcap.h.
It said Unresolved inclusion <pcap.h>
I installed libcap like this: sudo apt-get install libcap-dev
I restarted my machine.
And now I am still getting the warning that it cannot resolve pcap.h.
What am I doing wrong? Any ideas?
Try installing linux-headers, but you will need to know your kernel version:
Ex.:
tiago#dell:~$ sudo uname -a
Linux dell 3.11.0-20-generic #35~precise1-Ubuntu SMP Fri May 2 21:32:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
tiago#dell:~$ sudo apt-get install linux-headers-3.11.0-20
Reading package lists... Done
Building dependency tree
Reading state information... Done
linux-headers-3.11.0-20 is already the newest version.
0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.