jcmvbkbc

Код может выглядеть как-то так:

void OutFloat(double v);

sub sp,16
mov bp,sp
fstp qword ptr [bp + 8]
call OutFloat
add sp,16

Т.е. можно выгружать значение из сопроцессора прямо в то место, где будет исходящий параметр для вызова функции.
Ошибка возникает из-за того, что нет команд mov пересылающих значение из памяти в память.

Она работает и выводит в консоль "destruct". Но после этого объект никуда не исчезает.

Тебе предстоит узнать много нового. О том, что такое неопределённое поведение. О том, что удалять опреатором delete можно только объекты созданные оператором new. О том, что обращение к полям объекта после вызова деструктора -- это неопределённое поведение, так же как и вызов деструктора больше чем один раз. О том, что это забота программиста -- следовать правилам языка, а рантайм может закрывать глаза на ошибки, а может громко кричать и завершать программу при первой же возможности.

Она работает и выводит в консоль "destruct". Но после этого объект никуда не исчезает. К нему по прежнему можно обратиться и вывести значения xy. При этом по завершению работы программы, в консоль выводится "destruct" второй раз.

Ну а у меня твоя программа ожидаемо вылетает сразу же в месте вызова delete.

как правильно уничтожить объект?

Объект на стеке можно корректно уничтожить двумя способами: естественным -- выйдя из блока в котором он определён, и насильственным -- вызвав явно его деструктор и создав на его месте другой объект.

Укажите на ошибки в коде

Можно собрать программу с -g, и valgrind сам тебе укажет с точностью до строчки в исходниках, где была выделена утёкшая память.

как мне вводить строку с неизвестной длинной?

char *str = NULL;
scanf("%m[^\n]", &str);

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

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

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

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

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

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

Правильно ли я понимаю

Правильно.

bool& operator [] (int index) {
    return selfVector[index];
  }

должен стать

std::vector<bool>::reference operator [] (int index) {
    return selfVector[index];
  }

При компиляции выдает ошибку

А на скрине -- отладчик не может найти исходник для функции strcat. Т.е. всё с компиляцией нормально.

struct SYM* buildTree(struct SYM *psym[], int N)
...

void division(struct alphabet *alphabetLetter, int groupCount)
{
  int psysms[256];
...
  psysms[i] = &alphabetLetter[i];
...
  struct SYM *root = buildTree(psysms, alphabetLen);
...
}

Тут происходит что-то фееричное с типами: сначала указатели записываются в массив int, потом этот массив передаётся в buildTree который ожидает совсем другое.

.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 или соответствующим скриптом линковщика.

e.data.fd = cfd;
e.data.ptr = (void*)cfd;

epoll_data -- это union, не нужно его инициализировать сначала одним, а потом другим:

typedef union epoll_data {
               void    *ptr;
               int      fd;
               uint32_t u32;
               uint64_t u64;
           } epoll_data_t;

           struct epoll_event {
               uint32_t     events;    /* Epoll events */
               epoll_data_t data;      /* User data variable */
           };

в документации сказано, что там должен быть дескриптор серверного сокета

в документации сказано, что там должно быть значение, которое было в поле data во время вызова epoll_ctl.

Кроме того, 0 -- вполне нормальный файловый дескриптор.
Короче, я попробовал, у меня работает. Если у тебя не работает -- приведи весь код.

получается mainx узнает о том что есть функция printx() на этапе линковки [mainx.o] и [printx.o]?

Да.

Каким образом происходит передача информации в [mainx] что функция printx() существует?

Это работа линковщика связывать ссылки на неопределённые символы с определениями этих символов.
В main.o в месте вызова printx ставится команда вызова, в секции символов заводится неопределённый символ printx а в секции релокаций заводится запись, связывающая команду вызова с символом:

objdump -dr mainx.o
...
0000000000000000 <main>:
   0:   55                      push   %rbp
...
  3a:   89 c7                   mov    %eax,%edi
  3c:   e8 00 00 00 00          callq  41 <main+0x41>
                        3d: R_X86_64_PLT32      _Z6printxi-0x4
  41:   b8 00 00 00 00          mov    $0x0,%eax
  46:   c9                      leaveq 
  47:   c3                      retq   
...

readelf -a mainx.o
...
Relocation section '.rela.text' at offset 0x580 contains 12 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
...
00000000003d  001400000004 R_X86_64_PLT32    0000000000000000 _Z6printxi - 4
...

Symbol table '.symtab' contains 25 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
...
    20: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _Z6printxi
...

В printx.o в секции символов заводится символ, ассоциированный с адресом в коде, где определена функция printx:

readelf -a printx.cpp
...
Symbol table '.symtab' contains 24 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
...
    14: 0000000000000000    75 FUNC    GLOBAL DEFAULT    1 _Z6printxi
...

Здесь value == 0 -- потому что printx оказалась по адресу 0 в секции .text.

Линковщик объединяет входные секции согласно скрипту линковки, после чего вставляет конечные адреса символов в места, которые ссылаются на них.

Желательно привести наглядный пример.

Программа состоящая из следующих двух файлов может не собраться, потому что первые 6 символов имён функций из второго файла идентичны:

void f123456();
void main()
{
    f123456();
}

void f123456(void)
{
}

void f123457(void)
{
}

Есть ли подобные статьи для 64-бит архитектуры?

Зачем? В этой статье почти нет процессорной специфики -- там описаны потроха С-рантайма, библиотеки С и динамического линковщика. Любая программа на С для любой архитектуры при запуске проходит через те же стадии.

Следующий сегмент располагается через 10h от предыдущего.

Следующий параграф. Сегментный регистр может указывать на любой параграф.

Не понимаю, почему пронумеровано от 0 до F

По одному адресу на каждый байт параграфа -- от 0 до F -- как раз 16 разных адресов.