head	1.8;
access;
symbols
	RELENG_4_11_0_RELEASE:1.7.6.1
	RELENG_4_11:1.7.6.1.0.18
	RELENG_4_11_BP:1.7.6.1
	RELENG_4_10_0_RELEASE:1.7.6.1
	RELENG_4_10:1.7.6.1.0.16
	RELENG_4_10_BP:1.7.6.1
	RELENG_4_9_0_RELEASE:1.7.6.1
	RELENG_4_9:1.7.6.1.0.14
	RELENG_4_9_BP:1.7.6.1
	RELENG_4_8_0_RELEASE:1.7.6.1
	RELENG_4_8:1.7.6.1.0.12
	RELENG_4_8_BP:1.7.6.1
	RELENG_4_7_0_RELEASE:1.7.6.1
	RELENG_4_7:1.7.6.1.0.10
	RELENG_4_7_BP:1.7.6.1
	RELENG_4_6_2_RELEASE:1.7.6.1
	RELENG_4_6_1_RELEASE:1.7.6.1
	RELENG_4_6_0_RELEASE:1.7.6.1
	RELENG_4_6:1.7.6.1.0.8
	RELENG_4_6_BP:1.7.6.1
	RELENG_4_5_0_RELEASE:1.7.6.1
	RELENG_4_5:1.7.6.1.0.6
	RELENG_4_5_BP:1.7.6.1
	RELENG_4_4_0_RELEASE:1.7.6.1
	RELENG_4_4:1.7.6.1.0.4
	RELENG_4_4_BP:1.7.6.1
	RELENG_4_3_0_RELEASE:1.7.6.1
	RELENG_4_3:1.7.6.1.0.2
	RELENG_4_3_BP:1.7.6.1
	RELENG_4_2_0_RELEASE:1.7
	RELENG_4_1_1_RELEASE:1.7
	PRE_SMPNG:1.7
	RELENG_4_1_0_RELEASE:1.7
	RELENG_3_5_0_RELEASE:1.7
	RELENG_4_0_0_RELEASE:1.7
	RELENG_4:1.7.0.6
	RELENG_4_BP:1.7
	RELENG_3_4_0_RELEASE:1.7
	RELENG_3_3_0_RELEASE:1.7
	RELENG_3_2_PAO:1.7.0.4
	RELENG_3_2_PAO_BP:1.7
	RELENG_3_2_0_RELEASE:1.7
	RELENG_3_1_0_RELEASE:1.7
	RELENG_3:1.7.0.2
	RELENG_3_BP:1.7
	RELENG_2_2_8_RELEASE:1.6.2.1
	RELENG_3_0_0_RELEASE:1.7
	RELENG_2_2_7_RELEASE:1.6.2.1
	RELENG_2_2_6_RELEASE:1.6.2.1
	RELENG_2_2_5_RELEASE:1.6.2.1
	RELENG_2_2_2_RELEASE:1.6
	RELENG_2_2_1_RELEASE:1.6
	file_3_22:1.1.1.1
	DARWIN:1.1.1
	RELENG_2_2_0_RELEASE:1.6
	RELENG_2_1_7_RELEASE:1.1.6.2
	RELENG_2_1_6_1_RELEASE:1.1.6.2
	RELENG_2_1_6_RELEASE:1.1.6.2
	RELENG_2_2:1.6.0.2
	RELENG_2_2_BP:1.6
	RELENG_2_1_5_RELEASE:1.1.6.2
	RELENG_2_1_0_RELEASE:1.1.6.1
	RELENG_2_1_0:1.1.0.6
	RELENG_2_1_0_BP:1.1
	RELENG_2_0_5_RELEASE:1.1
	RELENG_2_0_5:1.1.0.4
	RELENG_2_0_5_BP:1.1
	RELENG_2_0_5_ALPHA:1.1
	RELEASE_2_0:1.1
	BETA_2_0:1.1
	ALPHA_2_0:1.1.0.2;
locks; strict;
comment	@# @;


1.8
date	2000.11.05.09.06.04;	author obrien;	state dead;
branches;
next	1.7;

1.7
date	97.03.18.19.37.39;	author mpp;	state Exp;
branches
	1.7.6.1;
next	1.6;

1.6
date	96.09.05.15.55.57;	author jdp;	state Exp;
branches
	1.6.2.1;
next	1.5;

1.5
date	96.07.05.19.26.52;	author jkh;	state Exp;
branches;
next	1.4;

1.4
date	96.04.18.19.05.58;	author jdp;	state Exp;
branches;
next	1.3;

1.3
date	96.02.07.21.02.20;	author wollman;	state Exp;
branches;
next	1.2;

1.2
date	95.09.21.20.10.52;	author joerg;	state Exp;
branches;
next	1.1;

1.1
date	94.09.03.19.31.22;	author csgr;	state Exp;
branches
	1.1.1.1
	1.1.6.1;
next	;

1.1.1.1
date	97.03.18.17.59.22;	author mpp;	state Exp;
branches;
next	;

1.1.6.1
date	95.10.06.01.33.04;	author davidg;	state Exp;
branches;
next	1.1.6.2;

1.1.6.2
date	96.05.04.15.35.04;	author jdp;	state Exp;
branches;
next	;

1.6.2.1
date	97.08.18.18.59.39;	author jdp;	state Exp;
branches;
next	;

1.7.6.1
date	2000.11.29.19.32.50;	author obrien;	state dead;
branches;
next	;


desc
@@


1.8
log
@Switch over to using the Christos Zoulas maintained version in contrib/
This also gives use the same exact results as NetBSD, thus sharing more
code with our bretheren.
@
text
@
#------------------------------------------------------------------------------
# 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
>4	lelong			>0		(version %d)
@


1.7
log
@Merge to resolve conflicts with file 3.22 merge.
@
text
@@


1.7.6.1
log
@MFC: switch over to using the Christos Zoulas maintained version in contrib/
@
text
@@


1.6
log
@Make "file foo.core" print the program name properly again.
@
text
@a0 1
# the following are for BSD/i386 (FreeBSD, NetBSD, etc.)
d2 75
a76 1
0	lelong&0377777777	041400407	BSD/i386
d86 1
a86 1
0	lelong&0377777777	041400410	BSD/i386 pure
d96 1
a96 1
0	lelong&0377777777	041400413	BSD/i386 demand paged
d106 1
a106 1
0	lelong&0377777777	041400314	BSD/i386 compact demand paged
a115 40
0	belong&0377777777	041400407	BSD/i386
>20	belong			<4096
>>0	byte&0xC0		&0x80		shared library
>>0	byte&0xC0		0x40		PIC object
>>0	byte&0xC0		0x00		object
>20	belong			>4095
>>0	byte&0x80		0x80		dynamically linked executable
>>0	byte&0x80		0x00		executable
>16	belong			>0		not stripped

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

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

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

d124 2
a125 2
7	string	\357\020\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0	i386 a.out core file
>1039	string	>\0	from "%s"
@


1.6.2.1
log
@Sync with -current.
@
text
@d1 1
d3 1
a3 75
#------------------------------------------------------------------------------
# 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
d13 1
a13 1
0	lelong&0377777777	041400410	FreeBSD/i386 pure
d23 1
a23 1
0	lelong&0377777777	041400413	FreeBSD/i386 demand paged
d33 1
a33 1
0	lelong&0377777777	041400314	FreeBSD/i386 compact demand paged
d43 40
d91 2
a92 2
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'
@


1.5
log
@New magic file with more politically correct identification of objects
and execs.
Submitted-By: Brent Nordquist <nordquis@@winternet.com>
@
text
@d92 1
a92 1
>1031	string	>\0	from "%s"
@


1.4
log
@Update an offset field for i386 a.out core files, so that the program
name comes out right again.

Note: Don't bring this change directly into the -stable branch.  The
appropriate offset for -stable is different.
@
text
@d1 1
a1 1
# the following are for 386BSD/FreeBSD
d3 8
a10 8
0	lelong			0410		pure executable
0	lelong			0413		demand paged executable
0	lelong&077777777	041400314	FreeBSD/i386 demand paged
>3	byte			&0x80
>>20	lelong			<4096		shared library
>>20	lelong			=4096		dynamically linked executable
>>20	lelong			>4096		dynamically linked executable
>3	byte			^0x80		executable
d13 8
a20 2
# This covers object files, and is better than "PDP-11 executable"
0	lelong			000000407	impure format
d22 60
@


1.3
log
@Recognize ld.so.hints file.  Don't ask.
@
text
@d26 1
a26 1
>1047	string	>\0	from "%s"
@


1.2
log
@Implement a rather gross hack to identify i386 a.out core files.
Takes advantage of some bytes in our current tss structure that
reliably have particular values (due to our current architecture or
CPU requirements).
@
text
@d27 5
@


1.1
log
@Changes to file(1) for FreeBSD:
- Makefile: bmake the sucker
- file.1, magic.5: replace __MAGIC__ and __SECTION__
- add Magdir/freebsd
- add file to usr.bin/Makefile

A note on the FreeBSD magic entry:
The magic number "000000407" is reported as "impure format".  This
stops file(1) telling us that our object files are "PDP-11 executables".
(Saying anything more than "impure format" would probably be bogus.
Submitted by:	Geoff.
@
text
@d17 10
@


1.1.1.1
log
@Upgrade to file version 3.22.

Obtained from: ftp://ftp.deshaw.com/pub/file/file-3.22.tar.gz
@
text
@d1 1
d3 8
a10 82
#------------------------------------------------------------------------------
# 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
d13 2
a14 8
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
a16 35
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
>4	lelong			>0		(version %d)
@


1.1.6.1
log
@Sync with main branch.
@
text
@a16 10
# 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	i386 a.out core file
>1047	string	>\0	from "%s"
@


1.1.6.2
log
@Update an offset field for i386 a.out core files, so that the program
name comes out right again.
@
text
@d26 1
a26 1
>1075	string	>\0	from "%s"
@
