Is there any way to execute linux commands in llvm pass and parse the objdump in it.
For example in python we can do as follows:
os.system('gcc example.c -o example')
os.system('objdump -o example > parsed.txt')
and parse it by using regular expression.So, similarly can we do it in llvm pass as well?
Related
I can disassemble raw binary file using the following command:
> aarch64-linux-gnu-objdump -m aarch64 -b binary -D file.bin
Can I achieve the same effect with llvm-objdump and how? Maybe any other tool from LLVM toolchain?
The easiest way I've found to do this using only LLVM tools is to first objcopy the binary into an ELF and then objdump the ELF.
Convert the file
llvm-objcopy -I binary -B aarch64 --rename-section=.data=.text,code file.bin file.elf
Let's go through this option-by-option:
-I binary: specifies that the input is in raw binary, rather than ELF, form.
-B aarch64 (LLVM 91): specifies that the binary is to be interpreted as AArch64 machine code.
--rename-section=.data=.text,code: specifies that the section named .data that automatically gets created when copying from a binary file should instead be named .text and marked as executable code. This allows disassembly with -d to work later.
Disassemble the file
llvm-objdump -d file.elf
This one's pretty self-explanatory (and the same as you'd write with GNU objdump). -d says to disassemble all code sections, and the only code section is the one that we marked using --rename-section in the previous step.
1This command is for LLVM 9 and below. LLVM 10 has removed the binary-specific -B option in favor of specifying your output target with the -O option, so you'd instead write -O elf64-littleaarch64.
I'm learning C++ and trying to run a simple hello world program. It compiles but it won't execute. It worked on Windows, but it won't run on Zorin OS.
I read online that the command to run it is ./test or ./test.exe.
This is what is looks like on the terminal:
$ g++ test.cpp -o test.exe
$ ./test
bash: ./test: No such file or directory
I looked at the questions similar to this, but none have helped me.
You can not expect to be able to execute the same commands on both Windows and Linux. They use different shells with different syntax and different behaviors.
Here's a typical example of compiling a file on GNU/Linux:
dir$ g++ myfile.cpp -o myfile
dir$ ./myfile
Here's a typical example of compiling the same file on Windows:
dir> g++ myfile.cpp -o myfile.exe
dir> myfile
Note in particular:
Linux doesn't use .exe or other extensions on executables, but Windows does.
Windows doesn't require specifying directory to run files in the working directory, but Bash on GNU/Linux generally does.
The only reason why the compilation command is as similar as it is is that g++ is a Unix tool ported to both platforms. Windows normally uses / instead of - for flags like -o
As commands get more complex, they start diverging even further.
From https://github.com/riscv/riscv-llvm,
Using the llvm-riscv is fairly simple to build a full executable
however you need riscv64-unknown-*-gcc to do the assembling and
linking. An example of compiling hello world:
$ clang -target riscv64 -mriscv=RV64IAMFD -S hello.c -o hello.S
$ riscv64-unknown-elf-gcc -o hello.riscv hello.S
My question is: if I change the LLVM backend and get it to emit a new instruction in the hello.S file, how will riscv64-unknown-elf-gcc know how to convert it into object code? Do I also need to make changes in riscv64-unknown-elf-gcc so that it knows the format of the new instruction?
riscv64-unknown-elf-gcc calls as, i.e. usually GNU as from the binutils to assemble assembly code (i.e. hello.S in your snippet) into executable machine code. Thus you would have to modify the binutils if you want to assemble a new instruction.
I have successfully run llvm opt with my toy transformation pass but do not see how to use 'opt' with built-in transformation passes http://llvm.org/docs/Passes.html#introduction
I have an empty hi.c file
int main(){
}
For example, if I want to use -instcount pass,
opt -instcount hi.c
gives me strange error.
opt: hi.c:1:1: error: expected top-level entity
int main(){
^
Use opt -instcount hi.bc does not work neither, with
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.
If I use opt -inst-count -f hi.bc, the output is a messy bitcode.
Question: how should we use 'opt' with built-in transformation passes (those from the link above)? Thanks for your ideas. 'opt -help' says
opt [options] <input bitcode file>
but my example above 'opt -instcount hi.bc' does not work as expected (see above).
At first: opt only works on bitcode / readable LLVM IR files. So passing a .c file will never work.
You have to compile the .c file first with clang:
clang -emit-llvm in.c -o input.bc
The Warning you encounter says basicly everything:
WARNING: You're attempting to print out a bitcode file. This is
inadvisable as it may cause display problems. If you REALLY want to
taste LLVM bitcode first-hand, you can force output with the `-f'
option.
opt has as output the probably modified bitcode file and since you do not support an output file it will print it to stdout. That is why you get "messy" bitcode.
To use opt the way it should be you can use /dev/null to get rid of the output:
opt -inst-count input.bc -o /dev/null
or support an output file
opt -inst-count input.bc -o output.bc
or print the output as readable LLVM IR to stdout
opt -inst-count input.bc -S
or print the ouptut as readable LLVM IR file to disk
opt -inst-count input.bc -S -o output.ll
I am in the process of writing a lightweight Octave binding to Quantlib, using SWIG and mkoctfile. I am following the documentation found on the SWIG and Octave homepage.
From the SWIG documentation:
27.2.1 Compiling a dynamic module
Octave modules are DLLs/shared objects having the ".oct" suffix.
Building an oct file is usually done with the mkoctfile command
(either within Octave itself, or from the shell). For example,
$ swig -octave -c++ example.i -o example_wrap.cxx $ mkoctfile
example_wrap.cxx example.c
where example.c is the file containing the gcd() implementation.
These are the files I have so far:
my SWIG interface file quantlib-octave.i
my function implementations quantlib-octave.cpp
a glue wrapper file generated using SWIG: quantlib-octave_wrap.cxx
This is the CLI output when I invoked mkoctfile:
root#yourbox:~/src/quantlib-octave$ mkoctfile quantlib-octave_wrap.cxx
quantlib-octave.cpp mkoctfile: unrecognized argument
quantlib-octave_wrap.cxx
The help information displayed when I type mkoctfile -h is not very useful.
Does anyone know why mkoctfile is complaining?
Version Info
SWIG Version 2.0.4
Compiled with g++ [x86_64-unknown-linux-gnu]
Configured options: +pcre
mkoctfile, version 3.6.0
Octave: 3.6.0
I managed to get this to work by renaming the extension of the generated file from .cxx to .cpp.
Maybe there is a better solution?