I am trying to build a kernel module for my DNS-320L NAS.
I have built crosstool-ng in a Debian lenny chroot environment but after I have compiled my kernel module and try and install it, I get:
insmod: error inserting 'kernel/net/ip4/ipip.ko': -1 Invalid module format
When I examine a working kernel module with readelf, I get:
~/ct-ng-build$ readelf -h ~/ct-ng-build/kernel/orig/ipip.ko
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 6696 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 51
But my module has a few differences:
~/ct-ng-build$ readelf -h ~/ct-ng-build/kernel/modules/lib/modules/2.6.31.8/kernel/net/ipv4/ipip.ko
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 6280 (bytes into file)
Flags: 0x600, GNU EABI, software FP, VFP
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 23
Section header string table index: 20
My cross_compile environment is:
$ echo $CROSS_COMPILE
arm-none-eabi-
make CROSS_COMPILE=${CROSS_COMPILE} INSTALL_PATH=~/ct-ng-build/kernel/install INSTALL_MOD_PATH=~/ct-ng-build/kernel/modules INSTALL_FW_PATH=~/ct-ng-build/kernel/firmware
My gcc is compiled:
$ ${CROSS_COMPILE}gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: ~/ct-ng-build/targets/src/gcc-4.3.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-none-eabi --prefix=~/x-tools/arm-none-eabi --with-local-prefix=~/x-tools/arm-none-eabi/arm-none-eabi//sys-root --disable-multilib --disable-libmudflap --with-sysroot=~/x-tools/arm-none-eabi/arm-none-eabi//sys-root --with-newlib --enable-threads=no --disable-shared --with-pkgversion=crosstool-NG-1.9.0 --with-arch=armv5te --with-tune=arm926ej-s --disable-__cxa_atexit --with-gmp=~/ct-ng-build/targets/arm-none-eabi/build/static --with-mpfr=~/ct-ng-build/targets/arm-none-eabi/build/static --enable-target-optspace --disable-nls --enable-symvers=gnu --enable-languages=c,c++
Thread model: single
gcc version 4.3.2 (crosstool-NG-1.9.0)
Any ideas how to make the OS/ABI to "UNIX - System V" and the Flags to "0x5000000, Version5 EABI" instead of "Arm" and "0x600, GNU EABI, software FP, VFP" ?
Or is there another problem?
Thanks!
--- EDIT ----
I am specifically trying to target my existing NAS OS:
Kernel 2.6.31.8 #1 armv5tel
C library gcc-4.3-mt-1.44.0
# /lib/libc-2.8.so
GNU C Library stable release version 2.8, by Roland McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
I have only been able to build a crosstool-ng environment so far using crosstool-ng-1.9.0, but it produced the binaries above.
I tried to set -mabi=apcs-gnu as per 3.17.2 ARM Options but the C library would not compile with strange "missing headers" errors (I may try again - possibly something with my chroot environment).
Build a new toolchain using crosstool-NG, but configure it for OABI rather than EABI.
See Configuring crosstool-NG.
All debian releases (for ARM) upto and including Lenny were OABI.
Ref: https://wiki.embeddedarm.com/wiki/EABI_vs_OABI
Even though your toolchain prefix is arm-none-eabi-, the binary it has produced looks like OABI.
I have OABI binaries that produce identical readelf output, and EABI binaries that have identical readelf output ("UNIX - System V") to what you want.
This question describes a similar but reversed situation to yours, i.e. his toolchain is generating EABI binaries but he needs OABI.
Apparently your toolchain was built to produce OABI but a misleading prefix was used.
You need to build a new toolchain using crosstool-NG, but configure it for EABI rather than OABI.
Newer versions of crosstool-NG actually make configuration for OABI difficult by forcing the selection EABI unless Use obsolete features is enabled.
ADDENDUM
You say "but configure it for OABI rather than EABI.", but how?
Using a crosstool-NG v1.18 installation, I can specify & build
* Linux kernel version 2.6.31.14,
* gcc version 4.3.2,
* binutils version 2.18a 2.19.1a,
* glibc version 2.8.
In order to unselect Target options ---> Use EABI (unselecting means use OABI),
I first have to select Paths and misc options ---> Use obsolete features.
In this version of crosstool-NG, Use EABI is automatically selected.
The description for the Use EABI menu item has:
Set up the toolchain so that it generates EABI-compliant binaries.
If you say 'n' here, then the toolchain will generate OABI binaries.
OABI has long been deprecated, and is now considered legacy.
Since OABI is considered deprecated in this version of crosstool-NG, the config symbol ARCH_ARM_EABI_FORCE is active unless Use obsolete features is specified.
I'm extracting some final comments here:
As #sawdust recommends, I am using EABI in the following CT-NG environment:
crosstool-NG version: 1.9.0
gcc 4.3.2
binutils 2.19.1
libc 2.8
gmp 4.3.2
mpfr 2.4.2
In order to get the GCC compiler to compile, I had to do a couple of hacks!
Namely:
remove res_hconf.c from targets/src/glibc-2.8/nscd (once, after the sources have been extracted)
remove res_hconf from the list of objects in the nscd/Makefile
create a soft link to stubs-32.h from stubs-.h in ~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root/usr/include/gnu (after the build had started).
I just had to download the correct Linux kernel and install it. The missing command was:
make ARCH=arm kirkwood_defconfig
Thereafter I just had to use make ARCH=arm menuconfig to customise things.
The gcc -v says:
Using built-in specs.
Target: arm-unknown-linux-gnueabi
Configured with: ~/ct-ng-build/targets/src/gcc-4.3.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=~/x-tools/arm-unknown-linux-gnueabi --with-sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --enable-languages=c,c++ --disable-multilib --with-arch=armv5te --with-tune=arm926ej-s --with-float=soft --disable-shared --with-pkgversion=crosstool-NG-1.9.0 --disable-sjlj-exceptions --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --with-gmp=~/ct-ng-build/targets/arm-unknown-linux-gnueabi/build/static --with-mpfr=~/ct-ng-build/targets/arm-unknown-linux-gnueabi/build/static --enable-threads=posix --enable-target-optspace --with-local-prefix=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --disable-nls --enable-symvers=gnu --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.3.2 (crosstool-NG-1.9.0)
Finally, to generate SYSV modules, I had to hack the kernel arch/arm/Makefile to remove the -mabi=aapcs-linux setting from the EABI section.
Now the error is:
"modprobe: can't load module ntfs (kernel/fs/ntfs/ntfs.ko): unknown symbol in module, or unknown parameter
Which is for another question :D
I still can't build a working kernel module (maybe because of the hacks!) but it might also be because I don't have a compatible kernel .config for the NAS.
The final changes were:
Not use unwind
Disable some kernel debugging and tracing
use SLAB instead of SLUB
The changes were selected by tracking the dmsg messages.
The resulting compiled kernel modules can now be loaded, if they are compatible with the compiled kernel.
(Note of warning: I got into a little trouble when I started adding iptables modules when I got locked out of my network connection! Be careful! Fortunately the modules are not reloaded at reboot. )
Related
I have a question when doing the binary analysis. For a given ELF file (hello.elf) that has already been identified for the ARM architecture, how can I quickly know if this ELF is for Cortex-A or Cortex-M? More specifically, I'm trying to identify the whole bare-metal images (or RTOS images like FreeRTOS) for the Cortex-M.
From the result of file hello.elf:
% file hello.elf
hello.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
We can only see that this ELF is for ARM.
And from the result of readelf -h ./hello.elf:
% readelf -h ./hello.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0xcb5
Start of program headers: 52 (bytes into file)
Start of section headers: 150896 (bytes into file)
Flags: 0x5000200, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 5
Size of section headers: 40 (bytes)
Number of section headers: 19
Section header string table index: 17
It's also only showing this file is for the ARM architecture.
So are there any other approaches that can quickly identify the target architecture of an ELF file?
If your binary follows the Arm ELF specification there is an attribute section that contains information on the cpu architecture and (if applicable) the architecture profile. This information can be extracted by readelf. Note that the information is the compiler and linkers view of things and can sometimes be wrong.
The first example below is from a binary built for Cortex-A8 and the second example is a binary built for Cortex-M33. Both are built using the IAR toolchain.
> readelf -A cortex-a8.out
Attribute Section: aeabi
File Attributes
Tag_conformance: "2.10"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_PCS_config: Bare platform
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: small
Tag_ABI_VFP_args: compatible
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
> readelf -A cortex-m33.out
Attribute Section: aeabi
File Attributes
Tag_conformance: "2.10"
Tag_CPU_arch: v8-M.mainline
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: Yes
Tag_FP_arch: FPv5/FP-D16 for ARMv8
Tag_PCS_config: Bare platform
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: forced to int
Tag_ABI_HardFP_use: SP only
Tag_ABI_VFP_args: compatible
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
First time posting a question here, open to feedback.
I am trying to get an executable running in AWS lambda, however I am getting the error "cannot execute binary file" which is quite vague (more outputs below).
I am hoping to identify what could be wrong, and why.
As a disclaimer I am not very good at c or python.
Currently my process has been to write a hello world program in c:
#include <stdio.h>
int main() {
printf("Hello World");
return 0;
}
Create an AWS instance which matches the Python 3.8 lambda runtime (Amazon Linux 2)
(Tried on Amazon Linux 1 with the same results)
Install compiler tools
sudo yum install gcc
sudo yum install glibc-static
Compile the program to a static executable
gcc -static -static-libgcc -static-libstdc++ hello.c -o testings
Also tried with less flags with similar results.
gcc -static hello.c -o testings
Have also tried as a 32 bit binary using -m32 flag. Tried this as looking at the cpu information for the lambda runtime showed a 32 bit processor.
Verify it has compiled with static dependencies
file testings
with the results
testings: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=7167aa934c751be053864ee555be8f6a46e4d62e, not stripped
and
ldd testings
with the results
not a dynamic executable
I've copied it to my local machine, changed the file permissions to allow execution, zipped it and uploaded it to lambda.
Which contains two files.
testings (the compiled c program)
lambda_function.py which looks like
import json
from subprocess import run, call
def lambda_handler(event, context):
call(["ls -ll"], shell=True)
print("using run")
out = run(["./testings"], shell=True)
print("printing result")
print(out.returncode)
print("printing output")
print(out.stdout)
print("printing error")
print(out.stderr)
return {
'statusCode': 200,
'body': json.dumps('hello')
}
The output of running this function is:
Response:
{
"statusCode": 200,
"body": "\"hello\""
}
Request ID:
"fb640125-6698-4777-841a-47228d4da930"
Function Logs:
START RequestId: fb640125-6698-4777-841a-47228d4da930 Version: $LATEST
total 1092
-rwxrwxrwx 1 slicer 497 426 Jan 13 07:03 lambda_function.py
-rwxrwxrwx 1 slicer 497 1111526 Jan 13 06:32 testings
using run
/bin/sh: ./testings: cannot execute binary file
printing result
126
printing output
None
printing error
None
END RequestId: fb640125-6698-4777-841a-47228d4da930
REPORT RequestId: fb640125-6698-4777-841a-47228d4da930 Duration: 24.81 ms Billed Duration: 100 ms Memory Size: 512 MB Max Memory Used: 58 MB Init Duration: 113.42 ms
I can run the executable on the AWS instance where it was compiled and on my local machine (Ubuntu 18.04.3 LTS).
I have read quite a few similar questions (running executable in lambda) and am aware this is not a new question, however I haven't managed to find a solution that works for me ( I suspect I am misunderstanding something fundamental, as this is a very new domain for me.)
Additional Information:
using readelf to look at the binaries headers:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x400950
Start of program headers: 64 (bytes into file)
Start of section headers: 699480 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 33
Section header string table index: 32
I have written simple Hello world program and compiled it with gcc-arm-linux-gnueabi compiler. It compiles well but when i try to execute it on ARM machine it complains "no such file or directory". I think gcc-arm-linux-gnueabi is for embedded Linux only due to e(mbedded)abi. Is it different from ARM Linux ABI?
Please help me to solve this problem
code is here
#include "stdio.h"
int main(void) {
printf("Hello world !\n");
return 0;
}
compiled as
arm-linux-gnueabi-gcc -Wall -o crosscomp hello.c
When i execute this crosscomp on target ARM machine error is crosscomp no such file or dir
EDIT When I was using arm-linux-gnueabi-gcc the entry point was not matching with the target machine entry point (readelf -l crosscom) but when I compiled with aarch64-linux-gnu-gcc entry point matched with target machine. But now error becomes permission denied on ./crosscomp. I tried with sudo which says crosscomp: no such command.
Note I posted same question on askubuntu https://askubuntu.com/questions/904685/cross-compilation-for-arm-error-no-such-file-or-directory but got no response.
The output of readelf is as below
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: AArch64
Version: 0x1
Entry point address: 0x400470
Start of program headers: 64 (bytes into file)
Start of section headers: 4488 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 26
This peculiar error message happens when the dynamic loader required by a particular executable is missing.
You can find out the name of the dynamic loader that you need by applying readelf to the problem executable. On my x86-64 Linux box, for example
$ readelf -l /bin/ls | grep 'program interpreter'
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
("program interpreter" is another name for "dynamic loader".)
So, run the above command on your crosscomp binary on your development box. (If you don't have readelf or you get error messages, try arm-linux-gnueabi-readelf.) The file named after "program interpreter:" needs to exist on your target ARM machine. If you don't know where to get it, please post the output of the above command + ls -l of the directory that should have the missing file in it.
I'm trying to compile a couple of programs for a little embedded device I own. It's a Little-endian MIPS (mipsel) processor. I retrieved this executable from it via telnet and the builtin ftp client:
root#debian-mipsel:/home/user/wansview/devel# readelf -h unzip1
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x401cc0
Start of program headers: 52 (bytes into file)
Start of section headers: 169960 (bytes into file)
Flags: 0x10001007, noreorder, pic, cpic, o32, mips2
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 24
Section header string table index: 23
root#debian-mipsel:/home/user/wansview/devel# file unzip1
unzip1: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked (uses shared libs), stripped
I then downloaded the MIPSEL version of Debian and I'm running it in QEMU. When I run the retrieved program above I get:
root#debian-mipsel:/home/user/wansview/devel# ./unzip1
-bash: ./unzip1: No such file or directory
Which I understand means it's not the right platform. Stubbornly I compiled a little hello world nonetheless to compare the ELF and file info. My hello world runs fine in Debian MIPSEL but also returns No such file or directory on the embedded device. It's readelf and file output is strikingly similar though:
root#debian-mipsel:/home/user/wansview/devel# readelf -h hello
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x400740
Start of program headers: 52 (bytes into file)
Start of section headers: 3652 (bytes into file)
Flags: 0x10001005, noreorder, cpic, o32, mips2
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 10
Size of section headers: 40 (bytes)
Number of section headers: 36
Section header string table index: 35
root#debian-mipsel:/home/user/wansview/devel# file hello
hello: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xeb3877062337a3dfd15cc09305691685ac0e8c57, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, stripped
I'm trying to better understand how my two systems differ and why the executables won't run on both. Are there any flags I could add to gcc to successfully compile for the embedded device?
More info about the device
# cat /proc/cpuinfo
system type : Ralink SoC
processor : 0
cpu model : MIPS 24K V4.12
BogoMIPS : 239.10
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16 dsp
VCED exceptions : not available
VCEI exceptions : not available
More info about Debian MIPSEL
(Binaries compiled on debian-mipsel won't run on the target embedded device)
root#debian-mipsel:/home/user/wansview/devel# cat /proc/cpuinfo
system type : MIPS Malta
processor : 0
cpu model : MIPS 24Kc V0.0 FPU V0.0
BogoMIPS : 1038.33
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8]
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
More info about Aboriginal Linux Mipsel
(Binaries compiled on Aboriginal Linux will run on the embedded device, and it can run binaries retrieved from the device. I'm not happy with it as it doesn't have make and other tools I need for compiling larger applications)
(mipsel:1) /home/wansview # cat /proc/cpuinfo
system type : MIPS Malta
machine : Unknown
processor : 0
cpu model : MIPS 24Kc V0.0 FPU V0.0
BogoMIPS : 1013.76
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
LDD
Here's a screenshot with ldd ran against my hello world and against unzip1 on both aboriginal linux and debian mipsel. Aboriginal Linux runs applications retrieved from the device just fine, and if I compile under Aboriginal Linux I can run the resulting binary on the embedded device. The reason I'm not content with Aboriginal is that doesn't have GNU make and other useful tools for larger applications, and no easy way to get them there.
You clearly need a different toolchain. On your Debian-mipsel, your toolchain uses glibc while your target uses uClibc.
So, maybe you would like to generate it by yourself using Buildroot:
wget http://buildroot.uclibc.org/downloads/buildroot-2014.11.tar.gz
tar zxf http://buildroot.uclibc.org/downloads/buildroot-2014.11.tar.gz
cd buildroot-2014.11
A trick to preconfigure for mipsel, R1 without soft-float (my will, check yours):
cat <<_EOF > .config
BR2_HAVE_DOT_CONFIG=y
BR2_mipsel=y
BR2_ARCH="mipsel"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_ARCH="mips32"
BR2_GCC_TARGET_ABI="32"
BR2_ARCH_HAS_ATOMICS=y
BR2_mips_32=y
# BR2_MIPS_SOFT_FLOAT is not set
BR2_MIPS_OABI32=y
_EOF
Finish your choice in Buildroot menuconfig, but you can
also keep it like this with save and exit.
make menuconfig # tweak options at your will,
make -j8 # takes 8 minutes on my machine
Then, your compiler can be found in ./output/host/usr/bin
A real example:
echo '#include <stdio.h>
int main(int argc, char* argv[]) {
printf("Hello World.\n");
return 0;
}' > hello.c
And compile it with your brand-new uClibc GCC compiler
output/host/usr/bin/mipsel-buildroot-linux-uclibc-gcc -o hello hello.c
A glimpse into the hello program: (didn't had time to fix my ldd...)
$ file hello
hello: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), not stripped
$ strings hello | grep "lib.*so*"
/lib/ld-uClibc.so.0
libgcc_s.so.1
libc.so.0
It's done with the toolchain and compile your program.
Now that you have time :-) see what Buildroot offers :
a complete distribution (in output/target/) for embedded systems in many architectures.
EDIT: Better chance to execute
You can statically link your program in order to maximize the chances to run your code on any target.
$ output/host/usr/bin/mipsel-linux-gcc -Wall -o hello -static hello.c
$ file ./hello
./hello: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), not stripped
And now, as that static version doesn't depend anymore on any external lib (only uClibc, here), this MIPS executable can even run on my x86_64 machine (thanks to binfmt and Qemu) :
$ uname -mo
x86_64 GNU/Linux
$ ./hello
Hello World.
Cheers.
Maybe i'm wrong but a simple fix (but not elegant way) in such cases could be to link the missing files to the existing ones:
ln -s /lib/libc.so.6 /lib/libc.so.0
like in this situation:
https://dev.openwrt.org/ticket/3083
I have a core file from embedded SH3 linux device, and gdb of the cross compiler environment (sh3-linux-gdb) in my host linux.
But I have problems loading the core file with gdb:
$ sh3-linux-gdb ./myprogram ./core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
...
This GDB was configured as "--host=i386-pc-linux-gnu --target=sh3-linux"...
GDB can't read core files on this machine.
(gdb)
Why it can't read the core file?
Is there any way to read the core file from target system to the cross gdb?
There is gdbserver in target machine (SH3-linux), but not gdb itself.
I am able to do runtime debuging of processes of target machine with gdbserver and sh3-linux-gdb, so sh3-linux-gdb should be correctly compiled.
EDIT:
readelf dump was requested:
[build]$ sh3-linux-readelf -a core
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: Renesas / SuperH SH
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 51
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000694 0x00000000 0x00000000 0x00200 0x00000 0
LOAD 0x001000 0x00400000 0x00000000 0x00000 0x01000 R E 0x1000
----- several boring lines removed -----
LOAD 0x05a000 0x29952000 0x00000000 0x01000 0x01000 RW 0x1000
LOAD 0x05b000 0x7be48000 0x00000000 0x15000 0x15000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.
Notes at offset 0x00000694 with length 0x00000200:
Owner Data size Description
CORE 0x000000a8 NT_PRSTATUS (prstatus structure)
CORE 0x0000007c NT_PRPSINFO (prpsinfo structure)
CORE 0x000000a0 NT_AUXV (auxiliary vector)
[build]$
EDIT2: Same problem with --core option:
$ sh3-linux-gdb ./myprogram --core=./core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-pc-linux-gnu --target=sh3-linux"...RUN GDB INIT
GDB can't read core files on this machine.
(gdb)
Try according to http://forums.freescale.com/t5/68K-ColdFire-reg-Microprocessors/GDB-can-t-read-core-files/td-p/70181
sh3-linux-gdb ./myprogram --core=./core
It may be a bug in the old gdb http://sourceware.org/bugzilla/show_bug.cgi?id=9542 - so try newer gdb (7) too.
Also possible that core was dumped in unsupported format. What is target's OS, version?
Can you post the output or readelf -a core ?
It is possible to debug your application, not with gdb directly but with gdb server. The first thing you have to do is to call gdbserver in the target system (you said in your question that this package is already installed) :
gdbserver AAA.BBB.CCC.DDD:port ./myprogram
It is assume that the target machine is accessible to an IP address : AAA.BBB.CCC.DDD:port. Once, you have done that, you can call gdb in your development machine by specifying the target remote server :
% gdb ./myprogram
% [...]
(gdb) target remote AAA.BBB.CCC.DDD:port
Note that the target remote server IP address are the same of the gdbserver.