jcmvbkbc

перекомпилируйте с параметром -fPIC
gcc -fPIC ./hello.s

"перекомпилируйте" в данном контексте означает "сгенерируйте другой ассемблерный код".

Код программы выглядит так:

Ну это же явно 32-битный код, компилируй его под 32 бита:
gcc -m32 hello.s -o hello

Фактически, по адресу 0x0060 лежит какой-то мусор, который никак не относится к тому, что я туда хотел положить.

Откуда взялся адрес 0x0060 и как вы поняли что там лежит?

TL;DR: код копирующий данные из FLASH в SRAM и обнуляющий .bss не линкуется по умолчанию. gcc вставляет ссылку на неопределённые символы __do_copy_data и __do_clear_bss в каждую единицу трансляции, в которой определяются объекты в секции .data и .bss соответственно. В написанных руками ассемблерных файлах их можно упомянуть явно.

--build - платформа где будут собираться исходники какой либо программы
--host - указываем где будет запускаться скомпиленная программа
--target - а это как я понимаю используется чтобы указать где будет собираться сам GCC?

Применительно к тулчейну
- build -- это машина, на которой ты строишь тулчейн. В твоём случае configure сам определит.
- host -- это машина на которой тулчейн будет выполняться. В твоём случае это то же самое, что build. Можно не указывать.
- target -- это машина, под которую тулчейн будет генерировать код.

Я их собрал с опцией (это верно в моем случае?):
HOST=x86_64-pc-nto-qnx6.5.0

Похоже на правду.

Но не просто собрать, а собрать так, чтобы собранный компилятор компилировал исходники под QNX.

Для этого тебе нужно понять, чем код, сгенерированный под QNX отличается от кода под ту же процессорную архитектуру, но под другую ОС.

.file "main.c"
Зачем в коде название файла с исходным кодом

Для генерации отладочной информации в формате DWARF.

.ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0"
...и версия моей убунты?

Это не версия твоей убунты, это строка идентификации компилятора, в которой оказалось имя твоей ОС.

Попадают ли они в исполняемый файл при окончательно компиляции и зачем используются?

Имена файлов попадают в таблицу символов как символы типа FILE и в секцию отладочной информации:

$ readelf -a hello | grep FILE
    28: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    37: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS hello.c
    38: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    41: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS

Если отладочная информация включает в себя номера строк, то они тоже будут ссылаться на имя файла, ассоциируя диапазон адресов с номерм строки в конкретном исходном файле.

Идентификационная строка компилятора попадает в секцию .comment объектного файла, а оттуда -- в исполняемый файл:

$ objdump -s -j .comment hello

hello:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 20284465 6269616e 20362e33  GCC: (Debian 6.3
 0010 2e302d31 382b6465 62397531 2920362e  .0-18+deb9u1) 6.
 0020 332e3020 32303137 30353136 00        3.0 20170516.

Всё это можно от исполняемого файла отрезать командой strip, objcopy или соответствующим скриптом линковщика.

Есть исходный код на Си, который вызывает функцию на ассемблере, но передаваемые аргументы как получить,

Гуглить словосочетание "имя целевой процессорной архитектуры" + ABI.
Например: x86_64 abi, x86 abi, arm64 abi...
В найденном документе искать раздел "parameter passing", "function calling" или с похожим по смыслу названием.

gcc не компилирует ничего. И версия почему-то 2.95
g++ всё компилирует спокойно и версия самая новая.

Криво установил? Конфликт с другой установкой?
Что выводят команды which gcc и which g++?

После установки musl-libc

что за линукс? как устанавливал musl-libc?

Что говорят следующие две команды?

$ /usr/bin/as
$ ldd /usr/bin/as

Что говорят следующие команды?

$ touch test.c
$ x86_64-linux-gnu-gcc -v -c test.c

Что означает условие?
if ! $LSS &>lss_log.txt

Если запуск программы $LSS (определённой в начале скрипта как ./lss) закончился неудачно (ненулевым кодом выхода), выполнить тело оператора if.

Последний шаг выполнить так (проверил в дебиане):

PF=opt/dev-tools-4.9 dpkg-buildpackage -rfakeroot -b

Для большинства опций -- будет переписано последним переданным значением. В частности это справедливо для -march и -mtune на x86.
Но в общем случае может быть что угодно, поскольку gcc может преобразовывать одни опции в другие согласно своим спекам перед вызовом собственно компилятора.