Does objdump require some information embedded in an executable that may be stripped by a compiler or something? I tried using it on an executable on Linux and this is the only output I get
objdump -D foo
foo: file format elf64-x86-64
Related
I am trying to convert UART loopback program to corresponding hex code. The command
riscv32-unknown-elf-gcc test.c -march=rv32im
riscv32-unknown-elf-gcc -o test test.c
both the command giving error
test.c:2:10: fatal error: rt/rt_api.h: No such file or directory
#include <rt/rt_api.h>
^~~~~~~~~~~~~
compilation terminated.
what is the exact command for compiling the c code with APIs, I am using Pulppissimo toolchain..
my program is
https://github.com/pulp-platform/pulp-rt-examples/tree/master/periph/uart/loopback
You have this error because rt/rt_api.h is not present in your riscv gcc search path.
To see the folders present in search path you can add -v option to your command or use:
riscv32-unknown-elf-cpp -v /dev/null /dev/null
What you can do is find the location of rt/rt_api.h and giving the path you find to gcc. Your command will be:
riscv32-unknown-elf-gcc -o test test.c -Ipath
I am using MinGW64 (Windows 7) without MSYS and I have the following problem:
I have one dll, written in C99, which has to have the .mexw64 suffix so it can be used by Matlab. I would like to be able to link this dll form another dll (mexw64) dynamically but gcc won't allow me to link directly. I cannot do static linking, because both dlls have many functions of the same name which can be hidden by not exporting their symbols when creating the shared library.
So far, I have tried:
To create a symbolic link (with correct suffix and preffix) using mklink. This works, but I was not able to run mklink from the makefile. Maybe it is due to the fact I am not using MSYS which could have ln -s (I havent checked).
To do the copy of the first dll and correcting the suffix and prefix. This worked better than I expected, because on runtime the second dll actually uses the original .mexw64 and not the dll copy. I guess it is just because the .mexw64 is found first, but why is that .mexw64 searched in the first place? How the system know it is actually a dll?
My question is, is this correct/safe enough? Are there any other options?
Thanks for comments.
You should build a proper implib, either as a linker output or from a .def.
Linker:
$ gcc -shared -o testimpl.mexw64 testimpl.c -Wl,--out-implib,libtestimpl.a
$ dlltool -I libtestimpl.a
testimpl.mexw64
Or create a .def file, specifying an explicit LIBRARY:
$ cat testimpl.def
LIBRARY testimpl.mexw64
EXPORTS
test #1
$ dlltool -d testimpl.def -l libtestimpl.a
$ dlltool -I libtestimpl.a
testimpl.mexw64
And finally, link stuff:
$ gcc -o test.exe test.c libtestimpl.a
# or
$ gcc -o test.exe test.c -L. -ltestimpl
$ grep testimpl.mexw64 test.exe
Binary file test.exe matches
I am trying to learn and use Elfreader by compiling a simple hello world program to a elf file as-
gcc -o test test.c
The file compiles correctly and runs perfect.
But when I try to run ReadElf on it by
readelf -h test
it returns
readelf: Error: Not and ELF file - it has the wrong magic bytes at the start
What do you think I am doing wrong, or is there a problem with my linker script?
Let me know if you need any additional info from me.
You can check file format type follow as :
$ objdump -t hello.exe
hello.exe: file format pei-i386
Maybe I guess your file is not elf format.
I was looking for an example on how to config OCLint or how to get it running. I made a search but nothing. Here at Stack Overflow there are just 3 posts related, just naming the library and on google just the official OCLint.org
The oficial docs says:
[user#localhost ~]$ oclint -help
OVERVIEW: OCLint, a static code analysis tool for Objective-C and related languages
USAGE: oclint [options] <input files>
OPTIONS:
-D <macro> - Predefine the specified macro
-F <directory> - Add directory to framework include search path
-I <directory> - Add directory to include search path
-R <directory> - Add directory to rule loading path
-arch <arch_name> - Specify which architecture (e.g. ppc, i386, x86_64, armv7) the compilation
should targets.
-help - Display available options (-help-hidden for more)
-include <file> - Include file before parsing
-isysroot <directory> - Add directory to SYSTEM include search path
-o <file> - Write output to <file>
-rc <paramemter>=<value> - Change the baheviour of rules
-stats - Enable statistics output from program
Choose report type:
-text - Plain text report
-html - HTML formatted report
-version - Display the version of this program
-x <value> - Input language type
But I would like a better explanation about macro (-D), and which path to choose for -I, -F, -R and what should I point at. A code example as
$ oclint path/to/file.m -D something -I something -F something -R something
And the output expected from that would be great.
Basically you just give oclint whatever you give to your compiler.
Alternatively, you may want to try oclint-xcodebuild if you are not familiar with compiler flags. This is a Python script that extracts flags from your Xcode build log file. See the usage here.
On AIX, I would run:
ar -X32 -t libdb2.a
and check for output to determine if there is a 32-bit object in the archive. Similarly with -X64 for checking for a 64-bit object. However, what about if I'm on another platform, and need to check the archive to see what it has? Usually I'm on Linux when I need to check, but I could just as easily be on Solaris or HP-UX.
I used to check for shr.o and shr_64.o, since that's what's being compiled, but those are starting to show up in actual messages that are in the archives, and thus the reliability of these have dropped to the point where I'm getting false positives.
If anyone has a pointer, preferably something I can do in perl, that'd be great.
I don't think there is an easy way. If you create two AIX archives, one 32-bit and one 64-bit, as follows:
$ cat a.c
int foo (void) { return 42; }
$ xlc -q32 a.c -c -o a32.o
$ xlc -q64 a.c -c -o a64.o
$ ar -X32 cr a32.a a32.o
$ ar -X64 cr a64.a a64.o
you end up with archives that are not in a readable format by the linux ar:
$ file a32.a a64.a
a32.a: archive (big format)
a64.a: archive (big format)
$ ar t a32.a
ar: a32.a: File format not recognized
$ ar t a64.a
ar: a64.a: File format not recognized
I tried using strings to see if anything obvious was in the archives, but found nothing. Your ony remaining option is to build a binutils package targetting AIX (download binutils, configure with option --target=powerpc-ibm-aix5.3, run make and voilà: you've got a tool called powerpc-ibm-aix5.3-ar somewhere in that build tree).
I'd suggest extract one of the .o files from the .a archive, and then running the file command on it. Example:
$ file fortune/fortune.o
fortune/fortune.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped
file isn't standard on every system, but can easily be compiled. Alternatively, there are a couple of perl modules which do the same thing as file.
ar offers the p command which prints the file in question. For example:
$ ar p libcurl.a base64.o > /tmp/base64.o
$ file /tmp/base64.o
base64.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
So... I'm one year late, but I just had the exact same problem. Here is how I solved it, I hope it helps someone:
$ ar t mylib.a
myobj1.o
myobj2.o
myobj3.o
$ mkdir /tmp/mylib
$ cp mylib.a /tmp/mylib
$ cd /tmp/mylib
$ ls
mylib.a
$ ar x mylib.a
$ ls
mylib.a
myobj1.o
myobj2.o
myobj3.o
$ file *
Possible outcomes:
mylib.a: current ar archive
myobj1.o: ELF 64-bit (...)
myobj2.o: ELF 64-bit (...)
myobj3.o: ELF 64-bit (...)
OR
mylib.a: current ar archive
myobj1.o: ELF 32-bit (...)
myobj2.o: ELF 32-bit (...)
myobj3.o: ELF 32-bit (...)
Explanation:
An archive library file is just a collection of ".o" files, when you use the "t" argument of ar you list the contents of the archive and when you use the "x" argument of ar you extract them. Type man ar for further instructions.