YQ Connector:Use docker-compose in integrational tests

1 files changed, 164 insertions, 0 deletions

diff --git a/contrib/libs/libmagic/magic/Magdir/freebsd b/contrib/libs/libmagic/magic/Magdir/freebsd
new file mode 100644
index 0000000000..66aff6caf2
--- /dev/null
+++ b/contrib/libs/libmagic/magic/Magdir/freebsd
@@ -0,0 +1,164 @@
+
+#------------------------------------------------------------------------------
+# $File: freebsd,v 1.9 2022/01/19 12:44:13 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
+
+#
+# FreeBSD kernel minidumps
+#
+0	string	minidump\040FreeBSD/	FreeBSD kernel minidump
+# powerpc uses 32-byte magic, followed by 32-byte mmu kind, then version
+>17	string	powerpc
+>>17	string	>\0			for %s,
+>>>32	string	>\0			%s,
+>>>>64	byte	0			big endian,
+>>>>>64	belong	x			version %d
+>>>>64	default	x			little endian,
+>>>>>64	lelong	x			version %d
+# all other architectures use 24-byte magic, followed by version
+>17	default	x
+>>17	string	>\0			for %s,
+>>>24	byte	0			big endian,
+>>>>24	belong	x			version %d
+>>>24	default	x			little endian,
+>>>>24	lelong	x			version %d