Можно использовать find
и промежуточный список файлов (files_to_copy
) решить Вашу проблему. Удостоверьтесь, что Вы находитесь в своем корневом каталоге, затем:
find LaTeX/ -type f -a -iname "*.pdf" > files_to_copy && rsync -avn --files-from=files_to_copy ~/ ~/Output/ && rm files_to_copy
Протестированный с Bash.
vmlinux
Это - ядро Linux в статически связанном формате исполняемого файла. Обычно Вы не должны волноваться об этом файле, это - просто промежуточный шаг в процедуре загрузки.
Сырые данные vmlinux файл могут быть полезны для отладки целей.
vmlinux.bin
То же как vmlinux, но в загрузочном необработанном формате двоичного файла. Вся информация о символах и перемещении отбрасывается. Сгенерированный от vmlinux
objcopy -O binary vmlinux vmlinux.bin
.
vmlinuz
vmlinux файл обычно сжимается с zlib
. С тех пор 2.6.30 LZMA
и bzip2
также доступны. Путем добавления далее загружаются и возможности распаковки к vmlinuz, изображение может использоваться для начальной загрузки системы с vmlinux ядром. Сжатие vmlinux может произойти с zImage или bzImage.
Функция decompress_kernel()
обрабатывает распаковку vmlinuz при начальной загрузке, сообщение указывает на это:
Decompressing Linux... done
Booting the kernel.
zImage (make zImage
)
Это - старый формат для маленьких ядер (сжатый ниже 512 КБ). При начальной загрузке это изображение становится загруженным низко в памяти (первые 640 КБ RAM).
bzImage (make bzImage
)
Большой zImage (это не имеет никакого отношения bzip2
), был создан, в то время как ядро вырастило и обрабатывает большие изображения (сжатый, более чем 512 КБ). Изображение становится загруженным высоко в памяти (выше ПОРШНЯ 1 МБ). Поскольку сегодняшние ядра являются путем более чем 512 КБ, это обычно - предпочтительный путь.
Контроль на шоу Ubuntu 10.10:
ls -lh /boot/vmlinuz-$(uname -r)
-rw-r--r-- 1 root root 4.1M 2010-11-24 12:21 /boot/vmlinuz-2.6.35-23-generic
file /boot/vmlinuz-$(uname -r)
/boot/vmlinuz-2.6.35-23-generic: Linux kernel x86 boot executable bzImage, version 2.6.35-23-generic (buildd@rosea, RO-rootFS, root_dev 0x6801, swap_dev 0x4, Normal VGA
vmlinux:
Несжатый и незагружаемый формат файла ядра Linux, просто промежуточный шаг к созданию vmlinuz
.
vmlinuz:
Сжатый и загружаемый файл ядра Linux. На самом деле это zImage
или bzImage
файл.
zImage:
Для старых ядер подойдет только 640k
размер барабана.
bzImage:
Big zImage
, нет 640k
предела размера плунжера, может быть намного больше.
Пожалуйста, ознакомьтесь с этим документом: vmlinuz Definition.
bzImage - цель, используемая для архитектур x86, работающих с BIOS ПК. Напротив, zImage является архитектурно-зависимой целью, наиболее часто используемой для встраиваемых устройств и хорошо работающей с их загрузчиками.
Сделайте подробную сборку ядра и найдите файлы
Этот подход может дать некоторое представление, никогда не устареет и поможет вам легко определить, какая часть системы сборки что делает.
Если у вас есть конфигурация сборки, которая создает один из файлов, выполните сборку с помощью:
make V=1 |& tee f.log
Измените комментарий к некоторому файлу C, чтобы принудительно создать ссылку re -(, например. init/main.c
подойдет ), если вы уже строили ранее.
Теперь осмотрите f.log
и найдите интересующие изображения.
Например, в v4.19 мы придем к выводу, что:
init/main.c
|
| gcc -c
|
v
init/.tmp_main.o
|
| CONFIG_MODVERSIONS stuff
|
v
init/main.o
|
| ar T (thin archive)
|
v
init/built-in.a
|
| ar T (thin archive)
|
v
built-in.a
|
| ld
|
v
vmlinux (regular ELF file)
|
| objcopy
|
v
arch/x86/boot/compressed/vmlinux.bin
|
| GZIP
|
v
arch/x86/boot/compressed/vmlinux.bin.gz
|
|.incbin
|
v
arch/x86/boot/compressed/piggy.S
|
| gcc -c
|
v
arch/x86/boot/compressed/piggy.o
|
| ld
|
v
arch/x86/boot/compressed/vmlinux (regular ELF file with gzipped code)
|
| objcopy
|
v
arch/x86/boot/vmlinux.bin
|
| arch/x86/boot/tools/build.c
|
v
arch/x86/boot/bzImage
Тонкие архивы упоминаются в:https://stackoverflow.com/questions/2157629/linking-static-libraries-to-other-static-libraries/27676016#27676016Это архивы, которые просто указывают на другие архивы/объекты вместо их копирования.
Ядро перешло от инкрементной компоновки к тонким архивам в версии 4.9, как описано в:https://stackoverflow.com/questions/29391965/what-is-partial-linking-in-gnu-linker/53959624#53959624
Полная интерпретация журнала
Когда мы начинаем читать подробные журналы сборки из резервной копии, сначала мы видим:
ln -fsn../../x86/boot/bzImage./arch/x86_64/boot/bzImage
так что эти два просто связаны символическими ссылками.
Затем мы ищем немного дальше x86/boot/bzImage
и находим:
arch/x86/boot/tools/build \
arch/x86/boot/setup.bin \
arch/x86/boot/vmlinux.bin \
arch/x86/boot/zoffset.h \
arch/x86/boot/bzImage
arch/x86/boot/tools/build
— это исполняемый файл, поэтому мы запускаем его, см. справочное сообщение:
Usage: build setup system zoffset.h image
и grep для поиска источника:
arch/x86/boot/tools/build.c
Итак, этот инструмент должен генерировать arch/x86/boot/bzImage
из arch/x86/boot/vmlinux.bin
и других файлов TODO. В чем смысл build
?
Если мы проследим за arch/x86/boot/vmlinux.bin
, то увидим, что это просто objcopy
изarch/x86/boot/compressed/vmlinux
:
objcopy \
-O binary \
-R.note \
-R.comment \
-S arch/x86/boot/compressed/vmlinux \
arch/x86/boot/vmlinux.bin
и arch/x86/boot/compressed/vmlinux
— это обычный файл ELF:
ld \
-m elf_x86_64 \
-z noreloc-overflow \
-pie \
--no-dynamic-linker \
-T arch/x86/boot/compressed/vmlinux.lds \
arch/x86/boot/compressed/head_64.o \
arch/x86/boot/compressed/misc.o \
arch/x86/boot/compressed/string.o \
arch/x86/boot/compressed/cmdline.o \
arch/x86/boot/compressed/error.o \
arch/x86/boot/compressed/piggy.o \
arch/x86/boot/compressed/cpuflags.o \
arch/x86/boot/compressed/early_serial_console.o \
arch/x86/boot/compressed/kaslr.o \
arch/x86/boot/compressed/kaslr_64.o \
arch/x86/boot/compressed/mem_encrypt.o \
arch/x86/boot/compressed/pgtable_64.o \
-o arch/x86/boot/compressed/vmlinux
ls -hlSr
говорит, что piggy.o
является самым большим файлом, поэтому мы ищем его, и он должен исходить из:
gcc \
-Wp,-MD,arch/x86/boot/compressed/.piggy.o.d \
-nostdinc \
-Ilinux/arch/x86/include \
-I./arch/x86/include/generated \
-Ilinux/include \
-I./include \
-Ilinux/arch/x86/include/uapi \
-I./arch/x86/include/generated/uapi \
-Ilinux/include/uapi \
-I./include/generated/uapi \
-include linux/include/linux/kconfig.h \
-D__KERNEL__ \
-m64 \
-O2 \
-fno-strict-aliasing \
-fPIE \
-DDISABLE_BRANCH_PROFILING \
-mcmodel=small \
-mno-mmx \
-mno-sse \
-ffreestanding \
-fno-stack-protector \
-Wno-pointer-sign \
-D__ASSEMBLY__ \
-c \
-o arch/x86/boot/compressed/.tmp_piggy.o \
arch/x86/boot/compressed/piggy.S
Префикс.tmp_
объяснен ниже.
arch/x86/boot/compressed/piggy.S
содержит:
.incbin "arch/x86/boot/compressed/vmlinux.bin.gz"
arch/x86/boot/compressed/vmlinux.bin.gz
происходит от:
cat arch/x86/boot/compressed/vmlinux.bin arch/x86/boot/compressed/vmlinux.relocs | \
gzip -n -f -9 > arch/x86/boot/compressed/vmlinux.bin.gz
происходит от:
objcopy -R.comment -S vmlinux arch/x86/boot/compressed/vmlinux.bin
происходит от:
LD vmlinux
что делает:
ld \
-m elf_x86_64 \
-z max-page-size=0x200000 \
--emit-relocs \
--build-id \
-o vmlinux \
-T./arch/x86/kernel/vmlinux.lds \
--whole-archive \
built-in.a \
--no-whole-archive \
--start-group \
lib/lib.a \
arch/x86/lib/lib.a \
--end-group \
.tmp_kallsyms2.o
vmlinux
огромен, но все показанные объекты крошечные в соответствии с ls -l
, поэтому я исследовал и узнал о новой ar
функции, о которой я не знал :тонких архивов.
В:
AR built-in.a
сборка делает:
ar \
rcsTPD \
built-in.a \
arch/x86/kernel/head_64.o \
arch/x86/kernel/head64.o \
arch/x86/kernel/ebda.o \
arch/x86/kernel/platform-quirks.o \
init/built-in.a \
usr/built-in.a \
arch/x86/built-in.a \
kernel/built-in.a \
certs/built-in.a \
mm/built-in.a \
fs/built-in.a \
ipc/built-in.a \
security/built-in.a \
crypto/built-in.a \
block/built-in.a \
lib/built-in.a \
arch/x86/lib/built-in.a \
drivers/built-in.a \
sound/built-in.a \
firmware/built-in.a \
arch/x86/pci/built-in.a \
arch/x86/power/built-in.a \
arch/x86/video/built-in.a \
net/built-in.a \
virt/built-in.a
T
указывает тонкий архив.
Затем мы видим, что все вложенные архивы также тонкие, например, поскольку я модифицировал init/main.c
, мы имеем:
ar \
rcSTPD \
init/built-in.a \
init/main.o \
init/version.o \
init/do_mounts.o \
init/do_mounts_initrd.o \
init/initramfs.o \
init/calibrate.o \
init/init_task.o
, который, наконец, поступает из файла C с помощью команды типа:
gcc \
-Wp,-MD,init/.main.o.d \
-c \
-o \
init/.tmp_main.o \
/work/linux-kernel-module-cheat/submodules/linux/init/main.c
Я не могу найти в логах переход с init/.tmp_main.o
на init/main.o
, что очень жаль... с:
git grep '\.tmp_'
мы видим, что это, вероятно, исходит от scripts Makefile.build
и связано с CONFIG_MODVERSIONS
, который я включил:
ifndef CONFIG_MODVERSIONS
cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
else
# When module versioning is enabled the following steps are executed:
# o compile a.tmp_<file>.o from <file>.c
# o if.tmp_<file>.o doesn't contain a __ksymtab version, i.e. does
# not export symbols, we just rename.tmp_<file>.o to <file>.o and
# are done.
# o otherwise, we calculate symbol versions using the good old
# genksyms on the preprocessed source and postprocess them in a way
# that they are usable as a linker script
# o generate <file>.o from.tmp_<file>.o using the linker to
# replace the unresolved symbols __crc_exported_symbol with
# the actual value of the checksum generated by genksyms
cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<
cmd_modversions_c = \
if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then \
$(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes)) \
> $(@D)/.tmp_$(@F:.o=.ver); \
\
$(LD) $(KBUILD_LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F) \
-T $(@D)/.tmp_$(@F:.o=.ver); \
rm -f $(@D)/.tmp_$(@F) $(@D)/.tmp_$(@F:.o=.ver); \
else \
mv -f $(@D)/.tmp_$(@F) $@; \
fi;
endif
Анализ выполнен с этой конфигурацией , которая содержит CONFIG_KERNEL_GZIP=y
.
aarch64arch/arm64/boot/Image
Просто несжатый objcopy
изvmlinux
:
objcopy -O binary -R.note -R.note.gnu.build-id -R.comment -S vmlinux arch/arm64/boot/Image
vmlinux
получается в принципе точно так же как и для x86 через тонкие архивы.
arch/arm/boot/zImage
Очень похоже на X86 со сжатым vmlinux
, но без магического build.c
шага. Сводка цепочки вызовов:
objcopy -O binary -R.comment -S arch/arm/boot/compressed/vmlinux arch/arm/boot/zImage
ld \
-EL \
--defsym _kernel_bss_size=469592 \
-p \
--no-undefined \
-X \
-T arch/arm/boot/compressed/vmlinux.lds \
arch/arm/boot/compressed/head.o \
arch/arm/boot/compressed/piggy.o \
arch/arm/boot/compressed/misc.o \
arch/arm/boot/compressed/decompress.o \
arch/arm/boot/compressed/string.o \
arch/arm/boot/compressed/hyp-stub.o \
arch/arm/boot/compressed/lib1funcs.o \
arch/arm/boot/compressed/ashldi3.o \
arch/arm/boot/compressed/bswapsdi2.o \
-o arch/arm/boot/compressed/vmlinux
gcc \
-c \
-o arch/arm/boot/compressed/piggy.o \
linux/arch/arm/boot/compressed/piggy.S
.incbin "arch/arm/boot/compressed/piggy_data"
cat arch/arm/boot/compressed/../Image | gzip -n -f -9 > arch/arm/boot/compressed/piggy_data
objcopy -O binary -R.comment -S vmlinux arch/arm/boot/Image
QEMU v4.0.0 может загружаться с bzImage, но не с vmlinux
Это еще одно важное практическое отличие:https://superuser.com/questions/1451568/booting-an-uncompressed-kernel-in-qemu
/arch/$ARCH/boot/compressed/misc.c
, посмотрите здесь: lxr.linux.no/#linux+v2.6.37/arch/x86/boot/compressed / … – wag 10.01.2011, 11:28