Obsolete unused backup project such as OK6410
guowenxue
2019-08-02 d304465ae7e95190acc898051acb4d7e4542a794
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
144
 
#------------------------------------------------------------------------------
# $File: freebsd,v 1.7 2009/09/19 16:28:09 christos Exp $
# 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            <1        \b)
0    belong            011421044151    ld.so hints file (Big Endian
>4    belong            >0        \b, version %d)
>4    belong            <1        \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