I'm new with this and I am a little messed with it:
I'm trying to compile netcat source code for MIPS in order to deploy it in my router, what I do is:
Download the toolchain for mips: mips-linux-gcc
Download netcat source and expand it to a folder
cd path/to/netcatsource
Execute:
CC=path/to/compiler/mips-linux-gcc ./configure --host=mips-linux
make
The make command works fine and trying the file command over compiled netcat file displays:
file netcat
OUTPUT: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), not stripped
For me everything seems fine, but if I execute ./netcat on my ubuntu box it works, and once I upload it to the router it displays the following error:
# ./netcat
Segmentation fault
This is the /proc/cpuinfo from my router:
# cat /proc/cpuinfo
system type : 963281T_TEF
processor : 0
cpu model : Broadcom4350 V7.5
BogoMIPS : 319.48
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
unaligned exceptions : 1395
Could anyone help me with this?
Regards
(I couldn't add a comment due to, I do not have enough points)
Try to static compile the source code
The problem may be happening because you do not have the necessary libraries on the router, maybe the binary is pointing to ld-linux.so and the router uses ld-uclibc.so. So try static build...
UPDATE
I recomend the buildroot toolchain, which by the way include netcat and many other tools like busybox
Related
When I try to run a simulation in SE mode in gem5 I get the following output:
warn: No dot file generated. Please install pydot to generate the dot file and pdf. build/RISCV/mem/mem_interface.cc:791: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) 0: system.remote_gdb: listening for remote gdb on port 7000 build/RISCV/sim/simulate.cc:194: info: Entering event queue # 0. Starting simulation... build/RISCV/sim/mem_state.cc:443: info: Increasing stack size by one page. build/RISCV/sim/mem_state.cc:99: panic: Someone allocated physical memory at VA 0x4000000000000000 without creating a VMA! Memory Usage: 619616 KBytes Program aborted at tick 2222000
I'm using the ELF-linux cross compiler. Compiling with the Newlib-ELF cross compiler simulates just fine, but the thing is that I need to use pthreads(openmp) and the Newlib compilation doesn't support it. To get a grip on things I tried to simulate in x86, and found out that it wont work either with a simple gnu/gcc compilation. Then I complied replicating what the test-progs folder did with docker and then it worked fine. Is this the way to go? Since the error says there are problems with physical memory, would compiling with docker help out, or am I missing an obviuos fix? How would go about compiling RISCV with docker (I couldn't find examples of docker+RISCV)?
I'm very new to the C language and have been tasked with modifying GRUB. What a way to learn, right? Anyway, I'm trying to debug my modified GRUB using VMWare and GDB. I've been able to get the debugger working before, but for some reason, every time I load up my VM and connect GDB, during the loading process of GRUB, I get:
.loadsym.gdb:1: Error in sourced command file:
The address where biosdisk.module has been loaded is missing
and I have no idea what to do about it. My first thought was, "Oh, I'll just add-symbol-file <file> and that'll fix it!" but apparently that tells GDB to forget every other symbol it loaded???? So I can't add the symbol-file and set a breakpoint.
My googling only returns one semi-relevant post that doesn't really go all that in-depth on fixing the issue.
This output may also be relevant.
info file biosdisk.module
Symbols from "H:\Workspace\GRUB\Bootloader\Trunk\grub-core\kernel.exec".
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
While running this, GDB does not access memory from...
Local exec file:
`H:\Workspace\GRUB\Bootloader\Trunk\grub-core\kernel.exec', file type elf32-i386.
Entry point: 0x9000
0x00009000 - 0x0000e6e0 is .text
0x0000e6e0 - 0x0000f68d is .rodata
0x0000f6a0 - 0x0000fe74 is .data
0x0000fe80 - 0x000175d4 is .bss
Ended up being that my codebase wasn't the same. That is, on my Windows host, I had one copy of my code and on my Ubuntu VM was another.
Using version control solved this issue.
I'm trying to compile the same lib on two x86 separate machines.
Both use the same toolchain (exactly same set of files) but have different Glibc versions.
When I run command LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --list ./libl2ps.so I notice the following discrepancy between the 2 Linux loaders:
Machine 1 (with Glibc 2.12):
19943: find library=libm.so.6 [0]; searching
19943: search path=/ebs/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64:...:/ebs/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/. (RPATH from file ./libl2ps.so)
19943: trying file=/ebs/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm.so.6
19943:
19943: find library=libgcc_s.so.1 [0]; searching
...
In this case the Linux loader selects lib libm.so.6 from the toolchain path based on RPATH of lib libl2ps.so.
Machine 2 (with Glibc 2.17):
10699: find library=libm.so.6 [0]; searching
10699: search path=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64:/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/lib64:/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib:/home/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/. (RPATH from file ./libl2ps.so)
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/lib64/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/./libm.so.6
10699: search cache=/etc/ld.so.cache
10699: trying file=/lib64/libm.so.6
As for Machine 1, the loader attempts from RPATH of libl2ps.so to select lib libm.so.6 from toolchain path but skip it for some reason and try further other paths. Finally it selects libm.so.6from the system path /lib64/.
The RPATH of the 2 libs lib2ps.so are exactly the same. The two files libm.so.6 are also exactly the same on both machines (checked with md5sum).
I don't understand this differences of behavior between the 2 Linux loaders.
Do you see any reason what would explain this discrepancy ?
Thank you very much for your answers.
Update:
Thank you yugr for your answer.
Output of readelf -h gives only differences on fields "Entry point address" and "Start of section headers" and there is no other differences so I think it will not help.
Regarding using dlopen()/dlerror(), I've done a little executable with the following statement:
dlopen("/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so", RTLD_LAZY);
On machine 1 it works as expected:
C++ dlopen demo
Opening libm-2.28.so...
Closing library...
On machine 2 it fails and dlerror() gives the following output:
Cannot open library: /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so: cannot open shared object file: No such file or directory
but the file libm-2-28.so really exists on my file system:
$ ls -l /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so
-rwxr-xr-x 1 frperies linseeusers_lte_espoo 1682944 Oct 5 13:50 /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic- linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so
This is very weird, what could lead to this situation ???
Thanks
Update 2:
That is true that I haven't pointed out that machine 1 is a RHEL6.8 distro while machine 2 is RHEL7.4 distro. I (naively?) didn't think this really matters...
On machine 1:
$ cat /proc/sys/kernel/osrelease
4.4.115-1.NSN.el6.x86_64
$ uname -a
Linux sq24-3 4.4.115-1.NSN.el6.x86_64 #1 SMP Mon Feb 12 12:35:46 CET 2018 x86_64 x86_64 x86_64 GNU/Linux
$ readelf -n libl2ps.so
Notes at offset 0x00000270 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: b598468830fdf2f61eda25553b9a367c4d28cdc9
On machine 2:
$ cat /proc/sys/kernel/osrelease
3.10.0-693.el7.x86_64
$ uname -a
Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
$ readelf -n libl2ps.so
Displaying notes found at file offset 0x00000270 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 5829181bc0502233748149369108915ea7b10e8f
Does it help ?
Thanks
Update 3:
$ readelf -n libm.so.6
Notes at offset 0x00000238 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 0d84c7247dd76008c096719043e5592735a1c4bd
Notes at offset 0x0000025c with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 4.4.0
So, how to interpret this ABI version number set to 4.4.0 ??
Thanks
Thank you yugr and Employed Russian for your answers!!
I will give it a try by upgrading my Kernel version on Machine 2.
Thanks
Regards
The error message that you see is the infamously confusing ENOENT errno. I see two instances of it in dl-load.c:
checking OS compatibility
loading non-setuid to setuid process
I suspect the first one fails in your case which would mean that OS kernel is incompatible between two machines. ld.so manpage indeed says that
Each shared object can inform the dynamic linker of the
minimum kernel ABI version that it requires. (This
requirement is encoded in an ELF note section that is viewable
via readelf -n as a section labeled NT_GNU_ABI_TAG.) At run
time, the dynamic linker determines the ABI version of the
running kernel and will reject loading shared objects that
specify minimum ABI versions that exceed that ABI version.
NT_GNU_ABI_TAG is 4.4.0 which means that you run a program expecting a minimum 4.4 kernel on a 3.10 kernel. Theoretically newer Glibc should run on older kernels as well but in your case Glibc was probly built with explicit --enable-kernel flag which prevents it's usage on kernels before 4.4 (see e.g. this explanation of --enable-kernel).
As a workaround, you may try to fool Glibc by overriding kernel version on machine 2 via
export LD_ASSUME_KERNEL=4.4.0
but it may not work if libm makes 4.4-specific syscalls that are not really present on 3.10.
There are many questions similar to mine on google, I have tried them all but none of them works so I have to post this question.
I'm trying to use Valgrind to detect memory leak on some binary files, which are compiled for my device (using Processor: ARM926EJ-S rev 5 (v5l)).
Therefore, I'm trying to cross compile Valgrind using the specific toolchain for my device.
Here is my process:
I'm using Valgrind 3.13.0 and Ubuntu 16
1/ cd Valgrind-3.13.0
2/ sed "s/armv7/arm/g" configure (so that it won't complain about unsupported architect).
3/ ./configure --host=arm-none-linux-gnueabi (using my specific cross compiler instead of the default on of Linux)
4/ make
The following error pops up:
error: bad value (cortex-a8) for -mcpu= switch
=> Since my device using ARM926EJ-S processor, I replace cortex-a8 with arm926ej-s of all files in Valgrin-3.13.0 folder.
Running above steps again and another error pops up:
m_dispatch/dispatch-arm-linux.S: Assembler messages:
m_dispatch/dispatch-arm-linux.S:104: Error: selected processor does not support `movw r1,#47'
m_dispatch/dispatch-arm-linux.S:105: Error: selected processor does not support `movw r2,#0'
m_dispatch/dispatch-arm-linux.S:157: Error: selected processor does not support `movw r1,#:lower16:vgPlain_stats__n_xindirs_32'
m_dispatch/dispatch-arm-linux.S:158: Error: selected processor does not support `movt r1,#:upper16:vgPlain_stats__n_xindirs_32'
m_dispatch/dispatch-arm-linux.S:165: Error: selected processor does not support `movw r1,#(((1<<15))-1)'
m_dispatch/dispatch-arm-linux.S:166: Error: selected processor does not support `movw r4,#:lower16:vgPlain_tt_fast'
m_dispatch/dispatch-arm-linux.S:169: Error: selected processor does not support `movt r4,#:upper16:vgPlain_tt_fast'
m_dispatch/dispatch-arm-linux.S:182: Error: selected processor does not support `movw r1,#:lower16:vgPlain_stats__n_xindir_misses_32'
m_dispatch/dispatch-arm-linux.S:183: Error: selected processor does not support `movt r1,#:upper16:vgPlain_stats__n_xindir_misses_32'
Makefile:3224: recipe for target 'm_dispatch/libcoregrind_arm_linux_a-dispatch-arm-linux.o' failed
What am I doing wrong?
ARM9 uses the old ARMv5 instruction set. From the error message, it looks like Valgrind's assembly code expects a newer ARM (ARMv7) instruction set than what your processor has.
You therefore may be out of luck and need to port the above assembler to ARMv4 to get valgrind to work.
I compiled a C program using -m32 gcc option . I want to profile this program using a Pin tool . My kernel is 64 bit.
I have tried :-
1) pin -t64 <64-bit toolname> -t <32-bit toolname> -- <application>
2) pin -t <32-bit toolname> -- <application>
3) pin -t <64-bit toolname> -- <application>
I have the same .cpp tool file for both the tools compiled differently for 32 bit and 64 bit architectures.
Case 3 invoked an error 'unable to load .. Check the architecture type' .
Cases 1 and 2 , the command was successful but produced some unexpected output , for ex names of images written into a file is empty in this case but contains proper results when executed with a 64-bit application . Which is the correct way to set up the pin tool for this case?
well i found a workaround to compile the 32bit library of pin ( i mean instcount0 ) in 64bit arch.
i did modify the config file related to building the library.
i have pin located in /opt/ so , i edited
/opt/pin-3.0-76991-gcc-linux/source/tools/Config
at line 38
# Define the architecture of the target
# ; TARGET ?= $(HOST_ARCH)
TARGET = ia32
ifeq ($(TARGET),ia32)
BITS := 32
else
BITS := 64
endif
i just changed the target to ia32. works just fine after build .
There are a few caveats to know when starting a program under pin control:
1) The pintool must be compiled in the same architecture than the instrumented program (so, if your program is 32-bit, your pin tool must be 32-bit).
2) Ensure your system is setup to execute 32-bit programs on a 64-bit OS (some linux systems still need ia32-libs and / or need to be prepared for executing 32-bit programs (e.g. sudo dpkg --add-architecture i386)
3) Ensure you have all required libraries for PIN
4) Use pin.sh
Your command should be:
pin -t pintool.so -- <program> <program-options>
If you still have problems it is probably a problem with your pintool code rather than pin itself.
Did you tried one of the simple example (like inscount) on your program ?
Check the version of your PIN binary.
file PIN_DIR/pin
I downloaded PIN kit from this link. My PIN binary is 32-bit. If yours is 64-bit version, you can modify codes that check system architecture in pin.sh, and run
PIN_DIR/pin.sh
That should give you a 32-bit version PIN binary.