[MLton] Experimental 64-bit binary package (& SVN sources)
skaller
skaller at users.sourceforge.net
Fri Mar 2 20:56:42 PST 2007
On Fri, 2007-03-02 at 22:15 -0600, Matthew Fluet wrote:
> skaller wrote:
> > On Sat, 2007-03-03 at 13:23 +1100, skaller wrote:
> > []
> > Extra info .. no idea if useful:
> >
> > (gdb) file /work/mlton/usr/lib/mlton/mlton-compile
> > BFD: /work/mlton/usr/lib/mlton/mlton-compile: don't know how to handle
> > OS specific section `.gnu.hash' [0x6ffffff6]
> > "/work/mlton/usr/lib/mlton/mlton-compile": not in executable format:
> > File format not recognized
>
> Well, I don't understand how mlton-compile isn't an executable. (BTW,
> mlton-compile.debug is the binary with debugging info.)
Neither do I: indeed:
skaller at rosella:/work/felix/svn/felix/felix/trunk$ readelf
-h /work/mlton/usr/lib/mlton/mlton-compile
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: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x401fe0
Start of program headers: 64 (bytes into file)
Start of section headers: 15948872 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 26
Section header string table index: 25
appears to show that the format conforms well enough for 'readelf'
command. Now, I do this:
readelf -S /work/mlton/usr/lib/mlton/mlton-compile
and get this:
There are 26 section headers, starting at offset 0xf35c48:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000400200 00000200
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 000000000040021c 0000021c
0000000000000020 0000000000000000 A 0 0 4
[ 3] .gnu.hash LOOS+ffffff6 0000000000400240 00000240
0000000000000064 0000000000000000 A 4 0 8
[ 4] .dynsym DYNSYM 00000000004002a8 000002a8
00000000000009c0 0000000000000018 A 5 1 8
[ 5] .dynstr STRTAB 0000000000400c68 00000c68
0000000000000399 0000000000000000 A 0 0 1
[ 6] .gnu.version VERSYM 0000000000401002 00001002
00000000000000d0 0000000000000002 A 4 0 2
[ 7] .gnu.version_r VERNEED 00000000004010d8 000010d8
0000000000000040 0000000000000000 A 5 2 8
[ 8] .rela.dyn RELA 0000000000401118 00001118
0000000000000060 0000000000000018 A 4 0 8
[ 9] .rela.plt RELA 0000000000401178 00001178
0000000000000888 0000000000000018 A 4 11 8
[10] .init PROGBITS 0000000000401a00 00001a00
0000000000000018 0000000000000000 AX 0 0 4
[11] .plt PROGBITS 0000000000401a18 00001a18
00000000000005c0 0000000000000010 AX 0 0 4
[12] .text PROGBITS 0000000000401fe0 00001fe0
0000000000b52f58 0000000000000000 AX 0 0 16
[13] .fini PROGBITS 0000000000f54f38 00b54f38
000000000000000e 0000000000000000 AX 0 0 4
[14] .rodata PROGBITS 0000000000f54f60 00b54f60
0000000000076afc 0000000000000000 A 0 0 32
[15] .eh_frame_hdr PROGBITS 0000000000fcba5c 00bcba5c
000000000000158c 0000000000000000 A 0 0 4
[16] .eh_frame PROGBITS 0000000000fccfe8 00bccfe8
0000000000005cdc 0000000000000000 A 0 0 8
[17] .ctors PROGBITS 00000000011d2cc8 00bd2cc8
0000000000000010 0000000000000000 WA 0 0 8
[18] .dtors PROGBITS 00000000011d2cd8 00bd2cd8
0000000000000010 0000000000000000 WA 0 0 8
[19] .jcr PROGBITS 00000000011d2ce8 00bd2ce8
0000000000000008 0000000000000000 WA 0 0 8
[20] .dynamic DYNAMIC 00000000011d2cf0 00bd2cf0
00000000000001b0 0000000000000010 WA 5 0 8
[21] .got PROGBITS 00000000011d2ea0 00bd2ea0
0000000000000010 0000000000000008 WA 0 0 8
[22] .got.plt PROGBITS 00000000011d2eb0 00bd2eb0
00000000000002f0 0000000000000008 WA 0 0 8
[23] .data PROGBITS 00000000011d31a0 00bd31a0
00000000003629d4 0000000000000000 WA 0 0 32
[24] .bss NOBITS 0000000001535b80 00f35b74
0000000000011300 0000000000000000 WA 0 0 32
[25] .shstrtab STRTAB 0000000000000000 00f35b74
00000000000000d2 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
you can see entry [3] is the .gnu.hash section that gdb seems
to be complaining about.
Now when I check an executable C++ program I produced I get this:
There are 39 section headers, starting at offset 0x10e28:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000400200 00000200
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 000000000040021c 0000021c
0000000000000020 0000000000000000 A 0 0 4
[ 3] .hash HASH 0000000000400240 00000240
0000000000000234 0000000000000004 A 4 0 8
[ 4] .dynsym DYNSYM 0000000000400478 00000478
00000000000006c0 0000000000000018 A 5 1 8
[ 5] .dynstr STRTAB 0000000000400b38 00000b38
.......
You can see here entry [3] is .hash type HASH ..
I just upgraded my distro, I now have:
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
GNU assembler 2.17 Debian GNU/Linux
(ld and other binutils seem to also be version 2.17)
Hmm.. there WAS some issue on Debian with broken binutils
at one stage. Anyhow I checked an older executable on
my system and it uses .hash not .gnu.hash
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
More information about the MLton
mailing list