Встраивание двоичных данных в исполняемый файл с помощью инструментов LLVM
Используемая вами реализация ZFS не опрашивает свои базовые устройства, если не происходит какой-либо активности.
Удаление диска из пула, к которому нет доступа, останется незамеченным, пока вы не получите к нему доступ.
Кажется, вам нужно добавить-z noexecstack(Это было добавлено и для двоичных файлов ELF в LLD 7.0.0). По умолчанию область исполняемого стека уязвима для эксплуатации через память стека . В вашем двоичном образе нет исполняемого стека, и я считаю, что именно поэтому он терпит неудачу. Ошибка сбивает вас с толку, поскольку она просит указать, какую целевую эмуляцию использовать для вашего стека (, которого у вас нет ).
Дэвид Херрманн проделал всю тяжелую работу и нашел кросс-платформенное решение, которое охватывает:
- ГНУ -лд
- ГНУ -золото
- GNU -libtool
- работа с кроссом -компиляция
- работа с LLVM
- не требуют никаких внешних не -стандартных инструментов
Магический призыв тогда:
$(LD) -r -o "src/mydata.bin.o" -z noexecstack --format=binary "src/mydata.bin"
И чаще всего вы хотите, чтобы этот двоичный сегмент читался только -:
$(OBJCOPY) --rename-section.data=.rodata,alloc,load,readonly,data,contents "src/mydata.bin.o"
ОБНОВЛЕНИЕ:
Я не мог проверить, так как моя система была:
$ uname -r
11.2-STABLE
$ ld -V
GNU ld 2.17.50 [FreeBSD] 2007-07-03
Supported emulations:
elf_x86_64_fbsd
elf_i386_fbsd
Я запустил виртуальную машину с FreeBSD 12.0, чтобы проверить это, и обнаружил это:
$ uname -r
12.0-RELEASE
$ ld -V
LLD 6.0.1 (FreeBSD 335540-1200005) (compatible with GNU linkers)
-z noexecstackбыл добавлен только в 7.0.0 и не указан на справочной странице для 6.0.1. Что еще более раздражает, указание неподдерживаемых значений для -zне вызывает ошибку!
Я не обновлялся до LLVM 7, чтобы проверить, помогает ли это. @Richard Smith сам нашел правильное решение, указав эмуляцию с помощью -mв другом ответе.Этот маршрут был бы намного проще, если бы LLD перечислил поддерживаемые эмуляции с помощью -V.
Если вы используете команду fileдля file.o, вы увидите, что она определяется как SYSV ELF. Это может быть достаточно хорошо для вас. Но если вы хотите точно такое же, как система, используйте elf_amd64_fbsd, который является псевдонимом для elf_x86_64_fbsd. Досадно, что ld -Vне выводит поддерживаемые эмуляции с LLD, как это делает GNU ld.
$ file /bin/cat
/bin/cat: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200086), FreeBSD-style, stripped
$ ld -r -b binary -m elf_amd64 -o data.o data.bin
$ file data.o
data.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
$ ld -r -b binary -m elf_amd64_fbsd -o data.o data.bin
$ file data.o
data.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
elf_amd64_fbsdявляется псевдонимом elf_x86_64_fbsd(, см. D7837 и D24356). Надеюсь, LLD добавит эмуляции в вывод -V.
После просмотра исходного кода правильной целевой эмуляцией для моей платформы является elf _amd64 . Таким образом, преобразование из двоичного файла в объектный файл работает с использованием:
ld -r -b binary -m elf_amd64 -o file.o file.svg
Стоит ли оно того? Это не было портативным в первую очередь.
Вам лучше преобразовать.svg в массив символов C; Пример:
$ cat Makefile
.SUFFIXES:.svg
.svg.c:
od -tx1 $< | sed 's/ /,0x/g;s/[^,]*//;1s/,/char $*[]={/;$$s/$$/};/' > $@
$ make file.o
od -tx1 file.svg | sed 's/ /,0x/g;s/[^,]*//;1s/,/char file[]={/;$s/$/};/' > file.c
cc -c -o file.o file.c
rm file.c
Конечно, вы можете установить имя массива на что-то другое/более надежное (, например. char $(subst /,_,$*)[] =...вместо char $*[] =...с GNU сделайте ). Кроме того, вы можете создать специальный преобразователь -hoc bin2c, написанный на C, вместо этой ужасной комбинации od+sed.