I have a .a file from which I want to get architecture information. Running file myFile.a results in file.a: current ar archive. How can I get more information on what architecture the file contains?
You can also skip the ar command and use readelf, via something like:
readelf -h <archive>.a | grep 'Class\|File\|Machine'
[00:32:15] /usr/lib $ readelf -h libxslt.a | grep 'Class\|File\|Machine'
File: libxslt.a(attrvt.o)
Class: ELF32
Machine: Intel 80386
File: libxslt.a(xslt.o)
Class: ELF32
Machine: Intel 80386
... #Trimmed this, it goes on a bit
File: libxslt.a(transform.o)
Class: ELF32
Machine: Intel 80386
File: libxslt.a(security.o)
Class: ELF32
Machine: Intel 80386
[00:32:24] /usr/lib $
In case it's relevant, here's the other information that you can get from readelf -h. I just trimmed the above with grep, obviously:
File: libxslt.a(security.o)
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: Intel 80386
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 2548 (bytes into file)
Flags: 0x0
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: 16
Section header string table index: 13
That output is for one of the object files in libxslt.a, but it gives the same information for each file.
Use
lipo -info libExample.a
It will Who the architecture it build for. Other functions like otool or file doesn't give the exact answer and sometimes it to verbose to get the correct information.
objdump is another option:
objdump -a file.a|grep 'file format'
http://linux.die.net/man/1/ar
extract the object files from the archive and inspect them with file(1), nm(1), etc.
I would suggest using objdump instead of lipo. objdump provides detailed information than lipo.
Related
On Ubuntu 20.10 x86_64
my sample code:
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("helloworld\n");
return 0;
}
Build:
gcc -o test test.c
Show entry point address:
readelf -h ./test
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: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1060
Start of program headers: 64 (bytes into file)
Start of section headers: 14824 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 13
Size of section headers: 64 (bytes)
Number of section headers: 31
Section header string table index: 30
Why does entry point address start at 0x1060 ? not 0x40000 ?
The binary is relocatable, and the segments have been packed against each other. The .text segment starts at 0x1050 in the file, and the entry point is relative to its location in the file, not the location it will ultimately be loaded.
For a non-relocatable file try readelf -h /usr/lib/klibc/bin/sh. This file is simpler in a number of ways, including not using an interpreter but actually being loaded as-is by the kernel.
We're not in x86 anymore. Relocatable binaries are the default for everything now, not just shared libraries. It's no longer a great pain to do relocatable stuff, and in a certain way it's cheaper than non-relocatable now because we have to emit the vector table anyway because the processor doesn't have 64 bit displacement.
As Nate Eldredge points out, compiling with -no-pie yields a non-relocatable binary, and I have verified the expected start address appears.
I am trying to find a call function in a binary file, so I tried this:
Compile my code (in C),
Use the command: mips-mti-linux-gnu-objdump -d myapp.elf> objdump.txt
My function in objdump.txt file: 9d003350: 42000828 myfunction 0x1
Now, I want to identify this function in myapp.bin when reading this from memory. But, I get this: 28080042.
I tried to use the command: xxd -ps myapp.bin> xxd.txt
Just can find: 28080042.
Is it possible to do that?
That's an endianness conflict. objdump and xxd are giving you the same bytes, they're just using different endianness.
Actual bytes in order:
28 08 00 42
Big endian value:
28 08 00 42
Little endian value:
42 00 08 28
xxd -p will print out the individual bytes in the file in the order in which they exist.
objdump is disassembling it, it knows that the bytes belong in groups of 4, and it's interpreting them as little-endian.
xxd can print in little-endian order, using the -e flag (with a default grouping of 4 bytes, use the -g flag to change the number of bytes per group). However, this is incompatible with the -p flag, because the -p flag ignores any grouping.
objdump can be made to print in big-endian order, using the -EB flag, however, this will affect what instructions it reports.
I'm trying to build a .deb package with debuild -i -us -uc -b and in the end I see:
Now running lintian...
warning: the authors of lintian do not recommend running it with root privileges!
W: libluajit-5.1-2: hardening-no-relro usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
E: libluajit-5.1-2: shlib-with-non-pic-code usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
W: luajit: hardening-no-relro usr/bin/luajit-2.1.0-alpha
W: luajit: binary-without-manpage usr/bin/luajit-2.1.0-alpha
Finished running lintian.
I have a hunch that I failed to define a "PIC code setup", which must be at the beginning of each external function:
The following code might appear in a PIC code setup sequence to compute
the distance from a function entry point to the TOC base:
addis 2,12,.TOC.-func#ha
addi 2,2,.TOC.-func#l
as specified by the ABI, page 99.
However I couldn't find the symbols which were non-PIC. Or maybe some relevant file that was not compiled with -fPIC?
Info:
system architecture: ppc64le
compiling .so library with: gcc -shared -fPIC
To find which symbols made your elf non-PIC/PIE (Position Independent Code/Executable), use scanelf from pax-utils package (on ubuntu, install it with sudo apt-get install pax-utils):
$ scanelf -qT /usr/local/lib/libluajit-5.1.so.2.1.0 | head -n 3
libluajit-5.1.so.2.1.0: buf_grow [0x7694] in (optimized out: previous lj_BC_MODVN) [0x7600]
libluajit-5.1.so.2.1.0: buf_grow [0x769C] in (optimized out: previous lj_BC_MODVN) [0x7600]
libluajit-5.1.so.2.1.0: buf_grow [0x76A0] in (optimized out: previous lj_BC_MODVN) [0x7600]
$ objdump -Sa /usr/local/lib/libluajit-5.1.so.2.1.0 | grep -A5 \ 7694:
7694: 00 00 80 39 li r12,0
7698: c6 07 8c 79 rldicr r12,r12,32,31
769c: 00 00 8c 65 oris r12,r12,0
76a0: 00 00 8c 61 ori r12,r12,0
76a4: a6 03 89 7d mtctr r12
76a8: 21 04 80 4e bctrl
On my case an absolute address was meant to be load on r12, but that's not possible for a dynamic library, so the linker used 0 for that parameter (I had to use #GOT operator, but that's the particular solution to my case).
On the luajit program, it's possible to define the address on linking time and it looks like this:
1003d0d4: 00 00 80 39 li r12,0
1003d0d8: c6 07 8c 79 rldicr r12,r12,32,31
1003d0dc: 07 10 8c 65 oris r12,r12,4103
1003d0e0: 30 ca 8c 61 ori r12,r12,51760
1003d0e4: a6 03 89 7d mtctr r12
Quite different right?
a much detailed explanation can be found on this wonderful Gentoo wiki page.
The failing lintian check is this:
# Now that we're sure this is really a shared library, report on
# non-PIC problems.
if ($objdump->{$cur_file}->{TEXTREL}) {
tag 'shlib-with-non-pic-code', $cur_file;
}
So you can probably find the offending file by looking for a .o that contains a TEXTREL dynamic section (which is making its way into your final link).
To do this, you can use readelf --dyanamic, in something like the following:
find . -name '*.o' |
while read obj
do
if readelf --dynamic "$obj" | grep -q TEXTREL
then
echo "$obj contains a TEXTREL section"
fi
done
I'm trying to run dfhack in a debugger. I'm running 64-bit Ubuntu Trusty, but Dwarf Fortress does not have a 64-bit build so I'm running 32-bit Dwarf Fortress. I have installed gdb via apt-get install gdb:i386.
Here's what happens when I start dfhack with gdb:
ben#australium:~/df_linux$ xvfb-run -a ./dfhack --gdb
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./libs/Dwarf_Fortress...(no debugging symbols found)...done.
(gdb) start
Temporary breakpoint 1 at 0x804bdec
Starting program: /home/ben/df_linux/libs/Dwarf_Fortress
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, 0xf7598b53 in main ()
from /home/ben/df_linux/libs/libgraphics.so
(gdb)
Here's what happens when I run it without gdb:
ben#australium:~/df_linux$ xvfb-run -a ./dfhack
Xlib: extension "RANDR" missing on display ":99".
Loading bindings from data/init/interface.txt
New window size: 1280x720
Font size: 10x12
Resizing grid to 128x60
Resizing font to 10x12
Resetting textures
DFHack is ready. Have a nice day!
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]#
The executable, the preloaded library, and gdb are all 32-bit:
ben#australium:~/df_linux$ readelf -h /home/ben/df_linux/libs/Dwarf_Fortress
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: Intel 80386
Version: 0x1
Entry point address: 0x804c980
Start of program headers: 52 (bytes into file)
Start of section headers: 18192664 (bytes into file)
Flags: 0x0
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: 28
Section header string table index: 27
ben#australium:~/df_linux$ readelf -h /home/ben/df_linux/hack/libdfhack.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x1b7e40
Start of program headers: 52 (bytes into file)
Start of section headers: 43686636 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 7
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
ben#australium:~/df_linux$ readelf -h /usr/bin/gdb
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: Intel 80386
Version: 0x1
Entry point address: 0x808cb95
Start of program headers: 52 (bytes into file)
Start of section headers: 5089368 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 28
Section header string table index: 27
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
This error comes from GDB starting your (64-bit) shell, which in turn execs your (32-bit) dfhack program.
You should only care about preloading into the target program. The fact that libdfhack.so was not preloaded into your shell is of no consequence, and you should simply ignore it.
I have executed the command "readelf -h test" ("test" is my binary program) on linux, and got following text:
ELF header:
Magic: 7f 45 4c 46 ....
Data: 2's complement, little endian
...
**Flags: 0x1007, noreorder, pic, cpic, o32, mips1**
...
Could you please let me know each meanings of flags of the above text in detail?
I have googled it, but could not find answers. Any comments would be appreciated.
ELF header flags are architecture-specific. For MIPS they are defined in SYSTEM V APPLICATION BINARY INTERFACE
EF_MIPS_NOREORDER 0x00000001
EF_MIPS_PIC 0x00000002
EF_MIPS_CPIC 0x00000004
EF_MIPS_ARCH 0xf0000000