Данная статья носит скорее просто познавательный характер, нежели практический, хотя знать то, о чем пойдет речь в этой статье желательно всем, кто намерен работать с QNX всерьез и надолго.
Стандарт исполняемых файлов Executable and Linking Format (ELF) был изначально разработан и опубликован UNIX System Laboratories (USL) как часть Application Binary Interface (ABI). После этого Tool Interface Standards (TIS) комитет выбрал этот стандарт для продвижения ELF в качестве формата для переносимых объектных файлов, которые могут работать на всех 32-ух битовых x86 процессорах фирмы Intel под любой операционной системой. Но это не значит, что ELF формат исполняемых файлов приемлем только для x86 архитектуры, просто для x86 архитектуры он стал de facto стандартом, а с самого начала он применялся и использовался для процессоров AT&T; WE 32100. Потом Sun взяла его за основу исполняемых файлов под SunOS для своих станций и серверов на базе Sparc процессоров. А уж затем этот стандарт вовсю начал использоваться для Intel x86 архитектуры.
Стандартный исполняемый файл ELF формата содержит множество сегментов, например такие как: .text — сегмент кода, .data — сегмент инициализированных данных (обычно только для чтения, сюда попадают строки, константные массивы и т.п.), .bss — сегмент неинициализированных данных программы, .dynamic — сегмент служебных данных о подгружаемых библиотеках во время запуска программы, .comment — информация о версиях, .init — код инициализации процесса, .fini — код окончания выполнения процесса и т.д. Этих сегментов большое множество, но в основном они все стандартные и несут в себе информацию, необходимую для правильной загрузки исполняемого файла в память и требуемых им библиотек. Также есть сегменты, отвечающие за хранение отладочной информации (.debug) и прочих опциональных данных (.line, .p_paddr), которые не являются критическими для загрузки и выполнения исполняемого файла и могут быть безопасно удалены.
Стандарт оговаривает, что могут быть произвольные дополнительные сегменты в ELF файлах, которые каждая операционная система может использовать для своих служебных нужд, но с одним условием — эта информация не должна влиять на переносимость бинарного кода между операционными системами на базе одной архитектуры процессоров. Т.е. производителям операционных систем было не рекомендовано использовать дополнительные сегменты в качестве несущих основную информацию об исполняемых файлах.
Теперь мы вплотную подошли к вопросу: «Каким же образом QSSL использует эту возможность у себя в операционной системе QNX 6.x ?». Но … прежде чем начать это обсуждение, я хочу уделить еще немного вашего внимания компилятору GNU C/C++, а именно его языковым расширениям, благодаря которым мы можем управлять созданием дополнительных сегментов даже на этапе компиляции.