summaryrefslogtreecommitdiffstats
path: root/contrib/file/Magdir/freebsd
blob: ee710fab5fd7abccb509546ce97aa35086a3762f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143

#------------------------------------------------------------------------------
# freebsd:  file(1) magic for FreeBSD objects
#
# All new-style FreeBSD magic numbers are in host byte order (i.e.,
# little-endian on x86).
#
# XXX - this comes from the file "freebsd" in a recent FreeBSD version of
# "file"; it, and the NetBSD stuff in "netbsd", appear to use different
# schemes for distinguishing between executable images, shared libraries,
# and object files.
#
# FreeBSD says:
#
#    Regardless of whether it's pure, demand-paged, or none of the
#    above:
#
#	if the entry point is < 4096, then it's a shared library if
#	the "has run-time loader information" bit is set, and is
#	position-independent if the "is position-independent" bit
#	is set;
#
#	if the entry point is >= 4096 (or >4095, same thing), then it's
#	an executable, and is dynamically-linked if the "has run-time
#	loader information" bit is set.
#
# On x86, NetBSD says:
#
#    If it's neither pure nor demand-paged:
#
#	if it has the "has run-time loader information" bit set, it's
#	a dynamically-linked executable;
#
#	if it doesn't have that bit set, then:
#
#	    if it has the "is position-independent" bit set, it's
#	    position-independent;
#
#	    if the entry point is non-zero, it's an executable, otherwise
#	    it's an object file.
#
#    If it's pure:
#
#	if it has the "has run-time loader information" bit set, it's
#	a dynamically-linked executable, otherwise it's just an
#	executable.
#
#    If it's demand-paged:
#
#	if it has the "has run-time loader information" bit set,
#	then:
#
#	    if the entry point is < 4096, it's a shared library;
#
#	    if the entry point is = 4096 or > 4096 (i.e., >= 4096),
#	    it's a dynamically-linked executable);
#
#	if it doesn't have the "has run-time loader information" bit
#	set, then it's just an executable.
#
# (On non-x86, NetBSD does much the same thing, except that it uses
# 8192 on 68K - except for "68k4k", which is presumably "68K with 4K
# pages - SPARC, and MIPS, presumably because Sun-3's and Sun-4's
# had 8K pages; dunno about MIPS.)
#
# I suspect the two will differ only in perverse and uninteresting cases
# ("shared" libraries that aren't demand-paged and whose pages probably
# won't actually be shared, executables with entry points <4096).
#
# I leave it to those more familiar with FreeBSD and NetBSD to figure out
# what the right answer is (although using ">4095", FreeBSD-style, is
# probably better than separately checking for "=4096" and ">4096",
# NetBSD-style).  (The old "netbsd" file analyzed FreeBSD demand paged
# executables using the NetBSD technique.)
#
0	lelong&0377777777	041400407	FreeBSD/i386
>20	lelong			<4096
>>3	byte&0xC0		&0x80		shared library
>>3	byte&0xC0		0x40		PIC object
>>3	byte&0xC0		0x00		object
>20	lelong			>4095
>>3	byte&0x80		0x80		dynamically linked executable
>>3	byte&0x80		0x00		executable
>16	lelong			>0		not stripped

0	lelong&0377777777	041400410	FreeBSD/i386 pure
>20	lelong			<4096
>>3	byte&0xC0		&0x80		shared library
>>3	byte&0xC0		0x40		PIC object
>>3	byte&0xC0		0x00		object
>20	lelong			>4095
>>3	byte&0x80		0x80		dynamically linked executable
>>3	byte&0x80		0x00		executable
>16	lelong			>0		not stripped

0	lelong&0377777777	041400413	FreeBSD/i386 demand paged
>20	lelong			<4096
>>3	byte&0xC0		&0x80		shared library
>>3	byte&0xC0		0x40		PIC object
>>3	byte&0xC0		0x00		object
>20	lelong			>4095
>>3	byte&0x80		0x80		dynamically linked executable
>>3	byte&0x80		0x00		executable
>16	lelong			>0		not stripped

0	lelong&0377777777	041400314	FreeBSD/i386 compact demand paged
>20	lelong			<4096
>>3	byte&0xC0		&0x80		shared library
>>3	byte&0xC0		0x40		PIC object
>>3	byte&0xC0		0x00		object
>20	lelong			>4095
>>3	byte&0x80		0x80		dynamically linked executable
>>3	byte&0x80		0x00		executable
>16	lelong			>0		not stripped

# XXX gross hack to identify core files
# cores start with a struct tss; we take advantage of the following:
# byte 7:     highest byte of the kernel stack pointer, always 0xfe
#      8/9:   kernel (ring 0) ss value, always 0x0010
#      10 - 27: ring 1 and 2 ss/esp, unused, thus always 0
#      28:    low order byte of the current PTD entry, always 0 since the
#             PTD is page-aligned
#
7	string	\357\020\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0	FreeBSD/i386 a.out core file
>1039	string	>\0	from '%s'

# /var/run/ld.so.hints
# What are you laughing about?
0	lelong			011421044151	ld.so hints file (Little Endian
>4	lelong			>0		\b, version %d)
>4	belong			<=0		\b)
0	belong			011421044151	ld.so hints file (Big Endian
>4	belong			>0		\b, version %d)
>4	belong			<=0		\b)

#
# Files generated by FreeBSD scrshot(1)/vidcontrol(1) utilities
#
0	string	SCRSHOT_	scrshot(1) screenshot,
>8	byte	x		version %d,
>9	byte	2		%d bytes in header,
>>10	byte	x		%d chars wide by
>>11	byte	x		%d chars high
OpenPOWER on IntegriCloud