I've recently installed a mips-linux-gnu-gcc crosstool in my linux machine which is based on i686. When I want to compile some codes, it showed me that error.
Every installing step was followed by http://developer.mips.com/tools/compilers/open-source-toolchain-linux/
After I installed the crosstool, I wrote a simple helloworld C file like this:
#include<stdio.h>
int main(void)
{
printf("Hello World!\n");
return 0;
}
But when I run:
/mips-linux-gnu-gcc hello.c -o hello -static
The compiler just print error:
bash: ./mips-linux-gnu-gcc: cannot execute binary file
I'm wondering maybe I've made some mistakes in some steps, but I can't figure it out.
Maybe some of you can help me, I'm confused by the problem.
The compiler you downloaded from MIPS is a 64-bit executable. Are you running a 32-bit host?
If you need a cross compiler for a 32-bit host targeting MIPS GNU/Linux, consider using the Sourcery CodeBench Lite compiler for MIPS GNU/Linux targets:
Sourcery CodeBench Lite for MIPS GNU/Linux
The link to the Sourcery CodeBench tools above comes from the MIPS pages just one level up from the link you provided:
MIPS Compilers Page
It looks like the mips-linux-gnu-gcc binary does not match the architecture of the machine you are trying to run it on. This might be something like a 32/64 bit mismatch.
Try using the free Mentor/Codesourcery MIPS gnu/gcc cross compilation tool chain instead. You can download from here.
Related
So my idea is to "lift" 64-bits Windows executable to LLVM bitcode (or whatever is higher than assembly) and then compile it back to 32-bit executable.
I found that RetDec and McSema can lift PE binary to LLVM IR (and optionally C), but McSema requires IDA pro so I haven't tried it yet.
I have installed MSVC v143 and Windows SDK version 10.0.19041.0:
Clang version:
clang version 13.0.1 (https://github.com/llvm/llvm-project 75e33f71c2dae584b13a7d1186ae0a038ba98838)
Target: x86_64-pc-windows-msvc
Thread model: posix
So I compile this Hello World code in C using Clang:
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
}
then clang hello.c -o hello.exe
Check hello.exe file type with WSL:
$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows
You can download it here.
Then I use RetDec to lift it to LLVM IR:
python retdec-decompiler.py --no-memory-limit hello.exe
Output: here
After that we get:
Compile bitcode back to executable:
clang hello.exe.bc -m32 -v -Wl,/SUBSYSTEM:CONSOLE -Wl,/errorlimit:0 -fuse-ld=lld -o hello.x86.exe
Output: here
I guess functions like _WriteConsoleW are Win32 APIs, but ___decompiler_undefined_function_0 might be generated from the decompiler by some way.
Also, the decompiled code has no main function, but it had entry_point function. From hello.exe.ll:
hello.exe.c also has entry_point instead of main:
And also, hello.exe.c doesn't have ___decompiler_undefined_function_0
I also tried running the bitcode with lli:
lli --entry-function=entry_point hello.exe.bc
Output: here
Here is the link to the files.
How to make this compile? Thanks!
That's very ambitious.
I'm going to go out on a limb and say that every windows application includes thousands of system header files, most of which use types whose size differs between 32- and 64-bit systems and many of which contains #ifdef or other platform-dependent differences. You'll have a large .ll file full of windows64-specific types and code.
If the developers at Microsoft saw windows64 as a good chance to drop some hacks that were needed for w95 code, then you'll have w32-incompatible code there, too.
What you have to do is what the wine developers did — add code to cater to each problem in turn. There will be thousands of cases to handle. Some of it will be very difficult. When you see the number 128 in the .ll file, was it sizeof(this_w64_struct) in the original source, sizeof(that_other_struct) or something else entirely? Should you change the number, and if so, to what?
You should expect this project to take at least years, maybe a decade or more. Good luck.
I am trying to do profiling of the code written in C++ with the target Architecture RISC-V. The code has been cross-compiled using RISC-V GNU Toolchain. My executable is unit_tests "ELF 64-bit LSB executable, UCB RISC-V, version 1 (GNU/Linux), dynamically linked,nterpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, with debug_info, not stripped" this information is retrieved using the file command.
What I am trying to do is the profiling of this using gprof. But to do the gprof gmon.out needs to be generated, to generate gmon.out the executable should be run first. I cannot run the binary elf of other architecture in some different architecture. I need a suggestion for this on which emulator or simulator does this for me or I can run on?
I have tried installing qemu using the follwing link:
https://www.google.com/url?q=https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html&sa=D&source=hangouts&ust=1597422417473000&usg=AFQjCNERr6pHYmj0SU6an3WkBRGQI52aTw
but not able to successfully install it.
Also have tried with spike but got "bad synccall" error. Any leads how can I resolve this issue.
I solved this issue using qemu in user mode. Following the instructions in the below link:
Manual-qemu-user
Where I could run the binary elf generated for target RISC-V, which I could run on x86 Linux machine.
The problem
We are trying to compile the spi_slave code on a raspberry pi. We used the native gcc compiler and the compile runs without any errors.
The problem is when I try to run the output:
/home/pi/spi_slave# ./build/output.elf
Segmentation fault
/home/pi/spi_slave# ./build/kernel.img
bash: ./build/kernel.img: cannot execute binary file
Tried to download the arm-none-eabi compiler from cambridge but it wont run:
/home/pi/spi_slave# ../arm-2008q3/bin/arm-none-eabi-gcc
bash: ../arm-2008q3/bin/arm-none-eabi-gcc: cannot execute binary file
Sourcecode
The code we are trying to compile is: http://tylernichols.me/wp-content/uploads/2012/11/raspberry_pi_bare_metal_spi_slave.zip
The only change we did was in the makefile, added a # in front of the ARMGNU var
#ARMGNU = arm-none-eabi
Environement
# uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
What am I doing wrong?
We have tried to find answers on google and stackoverflow for hours now without success. :/
arm-none-eabi is a non-linux compiler. It is for bare-metal applications. The difference is in the C library. However, gcc is intimately linked to the C library for normal compiles.
Then there is the code. It is not written for Linux. It is written for a bare-metal application. You need to load and run the code from the Raspberry-Pi boot loader (berryboot?) without Linux.
You can use the ARM Linux compiler to create code for a bare-metal application. However, it is probably easier for you to find a newlib compiler that is targeted for the Raspberry Pi. You can search for one on the web or try to build one yourself.
See: How to build gcc for Raspberry Pi and Bare-metal gcc.
I know that to compile to assembly, I should use the -Soption with gcc or g++, but how do I get MIPS assembly?
I tried
g++ -march=mips2 dll.c
but that gives the error
dll.c:1:0: error: bad value (mips2) for -march= switch
I saw a suggestion of the compile command mips_gcc, but I can't find how to install that compiler.
I'm using Ubuntu 64-bit, if that helps.
You need a version of gcc that is built as a MIPS cross compiler. You can download the free Mentor/Codesourcery MIPS gnu/gcc cross compilation tool chain from here. This toolchain is available for both Windows and Linux.
After downloading, installing and adding the tool chain to your path you would say:
mips-linux-gnu-g++ -march=mips32r2 -S dll.c
to compile your code to MIPS32R2 assembly.
UPDATE 8/2017:
It looks like Sourcery CodeBench free cross compiler for MIPS is no longer available at Mentor's site.
Try the free toolchain at Imagination's site.
Using MacPorts i have just installed arm-elf-gcc on to my MacBook Pro. This worked flawlessly and all seems to run fine.
However, after compiling a simple hello world test program in C and C++ and trying to run either on the target board (an ARM9 based board running Debian Linux) they immediately seg fault.
I'm a bit stuck as how to go about debugging this, as the target board has limited tools available and no gdb. I have successfully built and run other code using a Linux hosted cross compiler so it should work.
Any ideas?
Following the suggestion I have built and run gdbserver, I get the following in gdb on the host:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
I thought it may be a problem with the standard c libs so I removed any calls and have just an empty main that return 0, it is compiled with -Wall -g hello-arm.cpp -static. As a test I compiled the same source with a Linux hosted cross compiler and it runs and exits fine. The only difference I can see is the that Linux compiled version is over twice the size and the difference in output from the file command:
arm-elf-gcc: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
arm-*-linux: ELF 32-bit LSB executable, ARM, version 1, statically linked, for GNU/Linux 2.4.18, not stripped
The usual method of debugging in this situation is to run gdbserver on the target board, and connect to it (via ethernet) with gdb running on a host computer.
Alternately, you could try comparing the assembly in a Mac-compiled "Hello World" program and a (working) Linux-compiled one to see what's different.
After digging around for a couple of days I am starting to understand a bit more about embedded compilers. I wasn't really sure of the difference between arm-elf-gcc installed via MacPorts and the arm-unknown-linux toolchain I had installed on my Linux box. I just came across a pdf titled "An introduction to the GNU compiler" which contains the following paragraph:
Important: Using the GNU Compiler to
create your executable is not quite
the same as using the GNU Linker,
arm-elf-ld, yourself. The reason is
that the GNU Compiler automatically
links a number of standard system
libraries into your executable. These
libraries allow your program to
interact with an operating system, to
use the standard C library functions,
to use certain language features and
operations (such as division), and so
on. If you wish to see exactly which
libraries are being linked into the
executable, you should pass the
verbose flag
-v to the compiler.
This has important implications for
embedded systems! Such systems do not
usually have an operating system.
This means that linking in the system
libraries is almost always
meaningless: if there is no operating
system, for example, then calling the
standard printf function does not make
much sense.
So when I get back to my dev machine later I will determine the libraries linked in with the Linux build and add them to the arm-elf-gcc build.
I'll update this when I have more information but I just want to document my findings in case any one else has these problems.