1 |
On 01/29/15 21:02, Zac Medico wrote: |
2 |
>>> +# hppa_{32,64} |
3 |
>>> +# ia_{32,64} |
4 |
>>> +# m68k_{32,64} |
5 |
>>> +# mips_{eabi32,eabi64,n32,n64,o32,o64} |
6 |
>>> +# ppc_{32,64} |
7 |
>>> +# s390_{32,64} |
8 |
>>> +# sh_{32,64} |
9 |
>>> +# sparc_{32,64} |
10 |
>>> +# x86_{32,64,x32} |
11 |
>>> +# |
12 |
>>> +# NOTES: |
13 |
>>> +# |
14 |
>>> +# * The ABIs referenced by some of the above *_32 and *_64 categories |
15 |
>>> +# may be imaginary, but they are listed anyway, since the goal is to |
16 |
>>> +# establish a naming convention that is as consistent and uniform as |
17 |
>>> +# possible. |
18 |
>>> +# |
19 |
>>> +# * The Elf header's e_ident[EI_OSABI] byte is completely ignored, |
20 |
>>> +# since OS-independence is one of the goals. The assumption is that, |
21 |
>>> +# for given installation, we are only interested in tracking multilib |
22 |
>>> +# ABIs for a single OS. |
23 |
>> |
24 |
>> If you run readelf -h on (say) bash in any of our stage3's tarballs you |
25 |
>> always get "OS/ABI: UNIX - System V" irrespective of arch and abi. I |
26 |
>> don't know what you would get on BSD, but the field is totally |
27 |
>> irrelevant for our purposes despite the name. As far as I can tell, it |
28 |
>> is totally invariant across arches and abis. |
29 |
>> |
30 |
>> You can even unpack the the stage3's on an amd64 host and run readelf |
31 |
>> form the host on the chroot target and you'll get the elf header, so you |
32 |
>> don't need access to native hardware. |
33 |
>> |
34 |
>> The comment suggests that there might be some interesting information |
35 |
>> there, but there isn't. Maybe I'm just reading too much into it. |
36 |
> |
37 |
> Well, a quick google search seems to indicate that FreeBSD uses |
38 |
> EI_OSABI. I was specifically thinking about FreeBSD when I wrote that |
39 |
> comment, because I was aware that Gentoo/FBSD was using ELF, and I just |
40 |
> assumed that they would have a different EI_OSABI than Linux. |
41 |
|
42 |
Even there you'll get "UNIX - System V". I don't have a freebsd system |
43 |
ready to go, but here's what i get from my openbsd system: |
44 |
|
45 |
# uname -a |
46 |
OpenBSD obi.dis 5.6 GENERIC.MP#333 amd64 |
47 |
# readelf -h /bin/sh |
48 |
ELF Header: |
49 |
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |
50 |
Class: ELF64 |
51 |
Data: 2's complement, little endian |
52 |
Version: 1 (current) |
53 |
OS/ABI: UNIX - System V |
54 |
ABI Version: 0 |
55 |
Type: EXEC (Executable file) |
56 |
Machine: Advanced Micro Devices X86-64 |
57 |
Version: 0x1 |
58 |
Entry point address: 0x400260 |
59 |
Start of program headers: 64 (bytes into file) |
60 |
Start of section headers: 442512 (bytes into file) |
61 |
Flags: 0x0 |
62 |
Size of this header: 64 (bytes) |
63 |
Size of program headers: 56 (bytes) |
64 |
Number of program headers: 7 |
65 |
Size of section headers: 64 (bytes) |
66 |
Number of section headers: 17 |
67 |
Section header string table index: 16 |
68 |
|
69 |
|
70 |
I have *never* seen the OS/ABI be anything different. That's what |
71 |
struck me about your comment. Anyhow, we're far afield. |
72 |
|
73 |
I might install freebsd later in a vm just to have one handy and check. |
74 |
|
75 |
-- |
76 |
Anthony G. Basile, Ph. D. |
77 |
Chair of Information Technology |
78 |
D'Youville College |
79 |
Buffalo, NY 14201 |
80 |
(716) 829-8197 |