В чем разница расширений файлов bin, elf и l
Что проверяют
Понимаете ли вы, что расширение ничего не гарантирует, формат определяется содержимым, и знаете ли, что лежит в каждом артефакте сборки. Такой вопрос чаще задают тестировщикам встраиваемых систем и прошивок, а следом просят рассказать, как вы проверяли, что на устройство ушла нужная сборка.
Как отвечать
- ELF: стандартный формат исполняемых файлов, объектных файлов (
.o) и разделяемых библиотек (.so) в Linux и большинстве Unix-систем, его же выдают компиляторы для микроконтроллеров. Внутри заголовок с архитектурой и точкой входа, секции (.text,.data,.bss), таблица символов и, если её не вырезали, отладочная информация DWARF. Узнаётся по первым байтам7F 45 4C 46; - BIN: сырой образ без заголовка и метаданных, просто байты памяти подряд. Его получают из ELF, например командой
objcopy -O binary. Адрес загрузки внутри не записан, его знает загрузчик или программатор. Вне прошивок.binозначает просто двоичные данные, у каждой программы свои; - L: чаще всего исходник для генератора лексических анализаторов Lex или Flex, реже код на Lisp. Это текст, а не исполняемый файл. Если в контексте прошивок имелся в виду другой формат, например
.hex, лучше прямо уточнить у интервьюера.
Что с этим делает тестировщик: определяет формат командой file, смотрит заголовок через readelf -h, символы через nm, сверяет контрольные суммы артефактов с тем, что ушло в релиз. Отладчику (J-Link, OpenOCD) нужен ELF, потому что ему нужны символы, а загрузчик на устройстве обычно принимает BIN.
Где спотыкаются
Судят о формате по расширению. Переименованный файл остаётся тем, чем был, и file или первые байты в xxd скажут правду быстрее догадок.
Говорят, что BIN и ELF отличаются только размером. ELF несёт структуру и символы, BIN получается их отбрасыванием, и обратно ELF из него уже не восстановить.
Не проверяют, какая именно сборка попала в прошивку. Отладочный и релизный образ могут называться одинаково, поэтому сверять нужно версию, записанную в самом образе, и хэш файла, а не имя.