I'm trying to create a script which detects binary files and gets the version which compiled it. For example, if I have an executable which was compiled with gcc, I would like to get the version of gcc. I find out that I can use the Linux command ldd in order to check the executable, but is there a proper/cleaner and better way to do so?
Also as I understand, some of the python files also being compiled with gcc. How can I detect the version?
This depends on the binary format that you are looking at. As you mention Linux, I am assuming ELF files.
For that, you could use objdump -s --section .comment file:
my_executable: file format elf64-x86-64
Contents of section .comment:
0000 4743433a 20285562 756e7475 20372e33 GCC: (Ubuntu 7.3
0010 2e302d31 36756275 6e747533 2920372e .0-16ubuntu3) 7.
0020 332e3000 3.0.
For clang this looks like
my_executable: file format elf64-x86-64
Contents of section .comment:
0000 4743433a 20285562 756e7475 20382e31 GCC: (Ubuntu 8.1
0010 2e302d31 7562756e 74753129 20382e31 .0-1ubuntu1) 8.1
0020 2e300063 6c616e67 20766572 73696f6e .0.clang version
0030 20362e30 2e302d31 7562756e 74753220 6.0.0-1ubuntu2
0040 28746167 732f5245 4c454153 455f3630 (tags/RELEASE_60
0050 302f6669 6e616c29 00 0/final).
Another option, which is a bit more difficult to parse, would be to use strings:
strings hyrise/build-clang/hyriseClient | grep clang
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) | head -n 1
Note that on Linux, clang might use ld from gcc, so even if the executable was built using clang, you might see both "GCC" and "clang" in the output.
Related
How do I dump debug_loc section from an executable on Linux if default options (-g) are provided to GCC while compiling a C file? I use readelf linux utility.
GCC by default produces DWARF info in DWARF4 format, so if I pass -g-dwarf2 I can see .debug_loc section but how do inspect that section if info is generated with default options as I don't see the section in dump?
Do you use a recent version of binutils? On Ubuntu 14.04 I can build executable with "gcc -g test.c -o test".
With "readelf --debug-dump=info test" I can confirm it's using DWARF 4.
After that, you have (at least) two ways to dump the contents of .debug_line section.
readelf --debug-dump=decodedline test
This will dump decoded line number information. You get line==address mappings directly.
There is also:
readelf --debug-dump=rawline test
This gets you raw debug_line contents.
Usually, .debug_loc is generated for optimized code. Try optimizing your code using compiler flags.
I have a "Seagate Central" NAS with an embedded linux on it
$ cat /etc/*release
MontaVista Linux 6, (.dev-snapshot-20130726)
When I try to run my own application on this NAS, it will be "Killed"
without any notifications on dmesg or /var/log/messages
$ cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 4 (v6l)
BogoMIPS : 279.34
Features : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb02
CPU revision : 4
Hardware : Cavium Networks CNS3420 Validation Board
Revision : 0000
Serial : 0000000000000000
My toolchain is
Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/arm-none-linux-gnueabi
and my compile switches are
-march=armv6k -mcpu=mpcore -mfloat-abi=softfp -mfpu=vfp
How can I find out which process is killing my application, or what setting I have to change?
PS: I have created a simple HelloWorld application which is also not working !
$ ldd Hello
$ not a dynamic executable
readelf -a Hello
=> http://pastebin.com/kT9FvkjE
readelf -a zip
=> http://pastebin.com/3V6kqA9b
UPDATE 1
I have comiled a new binary with hard float
Readelf output
http://pastebin.com/a87bKksY
But no success ;(
I guess it is really a "lock" topic, which is blocking my application to execute. How can I find out what application kills mine ?
Or how can I disable such kind of function ?
Use these compiler switches:
-march=armv6k -Wl,-z,max-page-size=0x10000,-z,common-page-size=0x10000,-Ttext-segment=0x10000
See also this link regarding the toolchain.
You can run readelf -a against one of the built-in binaries (e.g. /usr/bin/nano) to see the proper text-segment offset in the section headers and page size / alignment in the program headers. The above compiler flags make self-compiled programs match the structure of built in binaries, and have been tested to work. It seems the Seagate Central NAS uses a page size / offset of 0x10000 while the default for ARM gcc is 0x8000.
Edit: I see you ran readelf already. Your pastebin shows
HelloWorld:[ 1] .interp PROGBITS 00008134 000134 000013 00 A 0 0 1
zip:[ 1] .interp PROGBITS 00010134 000134 000013 00 A 0 0 1
The value 10134-134=10000 (hex) yields the correct text-segment linker option. Further down (LOAD...) are the alignment specifiers, which are 0x8000 for your HelloWorld, but 0x10000 for the zip built-in. In my experience, soft-float has not caused problems.
Do you see any output at all?
Is your application dynamically linked?
If so, run the dynamic linker with the verbose option (you'll have to figure out the name of the dynamic linker on your platform, for Arch linux, it is ldd):
ldd --verbose 'your_program_name'
That will tell you if you're missing any dependencies (shared libs etc)
Run readelf -a 'your_program_name'
Make sure the file mentioned in Requesting program interpreter: /lib/ld-linux.so.2 exists. In this case, that filename is /lib/ld-linux.so.2
If this fails to help you figure out the problem, post the complete output of ldd --verbose 'your_program_name' and readelf -a 'your_program_name' in your question.
Another issue may be that the NAS software just kills foreign programs. I'm not sure why it would, but we're talking about a big corporation here (Seagate) and they have odd ideas of how the world works at times...
Edit, after looking at the pastebin of readelf:
From what I see, your Hello executable differs in 2 ways from the zip executable:
It is not dynamically linked, so that throws out a whole load of problems to look for.
There's a difference in how the 2 programs are built. zip does not use softfloats and Hello does. I suspect the soft-float dependency is due to one or both of these compiler switches: -mfloat-abi=softfp -mfpu=vfp
Hello Flags: 0x5000202, has entry point, Version5 EABI, soft-float ABI
zip Flags: 0x5000002, has entry point, Version5 EABI
I'd start with either:
Removing the soft-float option from the Hello build or:
make sure the soft-float emulation libraries are on the machine. I don't know what libs this would depend on, but I do remember MontaVista supplying them the last time I touched their software. It's been 8+ years since I touched MontaVista so it's clouded in a bit of old-memory fog.
This is an old thread, but I just wanted to add that I succeeded in compiling a "hello world" for this old NAS today.
Running ld-linux.so.3 <app> told me that
ELF load command alignment not page-aligned
Googling this, I found this: https://github.com/JuliaLang/julia/issues/33293, which pointed me to linker-options:
-Wl,-z,max-page-size=0x10000
Compiling with these options yielded en ELF that actually did work!
Are you sure your compilation options are correct ?
Try the following :
strace your application (if strace is present on the NAS)
downloas one of the NAS binary and run arm-none-linux-gnueabi-readelf -a on it, do the same on your helloworld program and see if the abi tag differ.
It looks like an illegal instruction issue, a floating point issue or an incompatible libc issue.
Edit : according to readelf output, nas program are compiled without soft float, you should try that.
I have an executable with two lines in comment section as readelf shows :
readelf -p .comment ac_test
String dump of section '.comment':
[ 0] GCC: (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
[ 39] GCC: (GNU) 4.6.0
The 4.3.4 compiler is the one installed in the Suse Linux but the 4.6 is compiled from sources. I have fix the PATH to point to 4.6 so the executable is compiled with.
I have the doubt if in any way the 4.3.4 toolchain is used.
My question is : Why do I have two compilers in the .comment section?, is any problem with that?,
Thanks.
Hard to say with that little bit of information, but it's probable that the comment from the 4.3.4 compiler comes from an object or library that was linked into your binary (i.e. you didn't compile it yourself with your 4.6 compiler).
I have an object file and am trying to disassemble it. When I use:
objdump -d example.o
I get an assembly in code in the file format of elf64-x86-64.
I am trying to disassemble this into ARM, how do I go about doing this?
If you want to do disassemble of ARM code, you'd better have an ARM tool chain, this is what I got:
http://bb.osmocom.org/trac/wiki/toolchain
After you have this, you can use arm-elf-objdump instead of objdump.
The command I used is
arm-elf-objdump -D -b binary -marm binaryfile.dat
If you look the manpage, you will find "-b" is followed by the file type. Sorry I don't know how to tell -b you want to analyze a .o file. "-marm" will tell the cpu is ARM.
Hope this can help you.
Compile binutils with the right target(s) to get binutils objdump binary that knows how to disassemble ARM.
http://www.gnu.org/software/binutils/
./configure --enable-targets=all for example.
Pick your targets, make and use the new objdump binary that is your-target-aware. See the binutils/README file for more information on targeting.
objdump -D t3c # stock binary
objdump: t3c: File format not recognized
vs.
./../../binutils-2.22/binutils/objdump -D t3c # latest compiled from source with all targets
In archive t3c:
t3c:arm: file format mach-o-le
Disassembly of section .text:
00002d94 <start>:
2d94: e59d0000 ldr r0, [sp]
...
Before disassembling the binary, check the filetype via "file", for example:
file dnslookup.o
dnslookup.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV),
not stripped
So now we know it is an ARM object or ELF file.
To disassemble arm object file use
arm-linux-gnueabi-objdump. In Ubuntu, "arm-linux-gnueabi-objdump" is the default disassembler for ARM binaries - no compilation is needed.
To install it, just do:
sudo apt-get install binutils-arm-linux-gnueabi
There are also other binaries inside this package that can further analyze the ARM binaries for you.
Install the ELDK and use arm-linux-objdump. You're trying to disassemble ARM instructions using a program that only knows x86.
We have an issue related to a Java application running under a (rather old) FC3 on an Advantech POS board with a Via C3 processor. The java application has several compiled shared libs that are accessed via JNI.
Via C3 processor is supposed to be i686 compatible. Some time ago after installing Ubuntu 6.10 on a MiniItx board with the same processor, I found out that the previous statement is not 100% true. The Ubuntu kernel hanged on startup due to the lack of some specific and optional instructions of the i686 set in the C3 processor. These instructions missing in C3 implementation of i686 set are used by default by GCC compiler when using i686 optimizations. The solution, in this case, was to go with an i386 compiled version of Ubuntu distribution.
The base problem with the Java application is that the FC3 distribution was installed on the HD by cloning from an image of the HD of another PC, this time an Intel P4. Afterwards, the distribution needed some hacking to have it running such as replacing some packages (such as the kernel one) with the i386 compiled version.
The problem is that after working for a while the system completely hangs without a trace. I am afraid that some i686 code is left somewhere in the system and could be executed randomly at any time (for example after recovering from suspend mode or something like that).
My question is:
Is there any tool or way to find out at what specific architecture extensions a binary file (executable or library) requires? file does not give enough information.
The unix.linux file command is great for this. It can generally detect the target architecture and operating system for a given binary (and has been maintained on and off since 1973. wow!)
Of course, if you're not running under unix/linux - you're a bit stuck. I'm currently trying to find a java based port that I can call at runtime.. but no such luck.
The unix file command gives information like this:
hex: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped
More detailed information about the details of the architecture are hinted at with the (unix) objdump -f <fileName> command which returns:
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000876c
This executable was compiled by a gcc cross compiler (compiled on an i86 machine for the ARM processor as a target)
I decide to add one more solution for any, who got here: personally in my case the information provided by the file and objdump wasn't enough, and the grep isn't much of a help -- I resolve my case through the readelf -a -W.
Note, that this gives you pretty much info. The arch related information resides in the very beginning and the very end. Here's an example:
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: 0x83f8
Start of program headers: 52 (bytes into file)
Start of section headers: 2388 (bytes into file)
Flags: 0x5000202, has entry point, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 31
Section header string table index: 28
...
Displaying notes found at file offset 0x00000148 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.16
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_CPU_unaligned_access: v6
I think you need a tool that checks every instruction, to determine exactly which set it belongs to. Is there even an offical name for the specific set of instructions implemented by the C3 processor? If not, it's even hairier.
A quick'n'dirty variant might be to do a raw search in the file, if you can determine the bit pattern of the disallowed instructions. Just test for them directly, could be done by a simple objdump | grep chain, for instance.
To answer the ambiguity of whether a Via C3 is a i686 class processor: It's not, it's an i586 class processor.
Cyrix never produced a true 686 class processor, despite their marketing claims with the 6x86MX and MII parts. Among other missing instructions, two important ones they didn't have were CMPXCHG8b and CPUID, which were required to run Windows XP and beyond.
National Semiconductor, AMD and VIA have all produced CPU designs based on the Cyrix 5x86/6x86 core (NxP MediaGX, AMD Geode, VIA C3/C7, VIA Corefusion, etc.) which have resulted in oddball designs where you have a 586 class processor with SSE1/2/3 instruction sets.
My recommendation if you come across any of the CPUs listed above and it's not for a vintage computer project (ie. Windows 98SE and prior) then run screaming away from it. You'll be stuck on slow i386/486 Linux or have to recompile all of your software with Cyrix specific optimizations.
Expanding upon #Hi-Angel's answer I found an easy way to check the bit width of a static library:
readelf -a -W libsomefile.a | grep Class: | sort | uniq
Where libsomefile.a is my static library. Should work for other ELF files as well.
Quickest thing to find architecture would be to execute:
objdump -f testFile | grep architecture
This works even for binary.