jcmvbkbc

В чем может быть проблема?

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

Вот эта структура:

struct IDTPtr {
    uint16_t limit;
    uint32_t base;
};

должна быть определена с атрибутом packed, иначе компилятор вставляет паддинг для выравнивания поля base на границу uint32_t, из-за чего в IDT загружается неверный адрес.

Ну и, вдобавок, нельзя делать iret из середины с++-функции, потому что компилятор организовал в ней кадр стека и вместо возврата iret снимает и интерпретирует мусор из этого кадра:

001000e6 <SimpleOS::IDT::dividing_by_zero()>:
  1000e6:       55                      push   %ebp
  1000e7:       89 e5                   mov    %esp,%ebp
  1000e9:       53                      push   %ebx
  1000ea:       83 ec 04                sub    $0x4,%esp
  1000ed:       e8 15 01 00 00          call   100207 <__x86.get_pc_thunk.ax>
  1000f2:       05 06 11 00 00          add    $0x1106,%eax
  1000f7:       83 ec 0c                sub    $0xc,%esp
  1000fa:       8d 90 08 fe ff ff       lea    -0x1f8(%eax),%edx
  100100:       52                      push   %edx
  100101:       89 c3                   mov    %eax,%ebx
  100103:       e8 4c 00 00 00          call   100154 <SimpleOS::Terminal::print(char const*)>
  100108:       83 c4 10                add    $0x10,%esp
  10010b:       fa                      cli
  10010c:       cf                      iret
  10010d:       90                      nop
  10010e:       8b 5d fc                mov    -0x4(%ebp),%ebx
  100111:       c9                      leave
  100112:       c3                      ret

Нужны подробности сборки. Согласно спецификации заголовок multiboot должен быть в пределах 8192 байт от начала, но если в сборку не подсовывать никаких дополнительных ключей и потом пытаться загружать elf-файл, то в нём multiboot header может оказаться дальше 8К от начала:

$ gcc -m32 boot.s -nodefaultlibs -nostartfiles -Wl,-Tlinker.ld -no-pie -o boot.elf
$ readelf -S boot.elf
There are 8 section headers, starting at offset 0x3140:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .note.gnu.bu[...] NOTE            00100000 001000 000024 00   A  0   0  4
  [ 2] .multiboot        PROGBITS        00101000 003000 00000c 00      0   0 4096
  [ 3] .text             PROGBITS        00102000 002000 000009 00  AX  0   0 4096
  [ 4] .bss              NOBITS          00103000 003000 004000 00  WA  0   0 4096
  [ 5] .symtab           SYMTAB          00000000 00300c 0000a0 10      6   9  4
  [ 6] .strtab           STRTAB          00000000 0030ac 00004d 00      0   0  1
  [ 7] .shstrtab         STRTAB          00000000 0030f9 000044 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

При такой сборке секция .multiboot оказалась по смещению 0x3000.

Сигналы доходят до меги, но она не включает ни один из светиков.

Я бы начал с отладки простым безусловным включением led на старте программы. Потому что 1К резистор последовательно со светодиодом с падением в 2В ограничивает ток 3ма, чего, скорее всего, недостаточно для заметного свечения.

Если записать вывод данных в файл
# /opt/speedtest/speedtest | tee spdt.log
то в файле не видно промежуточных значений значений.

Дело в том, что консольная программа может определить, направлен ли её вывод в терминал или в файл, и вести себя по разному, в зависимости от этого. Понаблюдать, что и как именно программа выводит можно запустив её под strace, например так:

strace -f -e ioctl,write -o log <program command line>

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

Что это значит

подозреваю, что вот эта часть: ���`�B��Χh� �l<*�� !����� -- это вывод скетча на 9600. Откуда LoadProhibited -- непонятно.

можно ли это как-то исправить?

только разобравшись, что происходит. idf.py monitor обычно декодирует стек трейс и выводит соответствующие строчки исходников, можно начать отсюда.

Для выхода из вложенных циклов при try/catch в случае исключения произойдёт свертка стека

stack unwinding или развёртка стека происходит при выходе из одного или более вложенных вызовов, т.е. когда текущим должен стать более ранний кадр стека. При выходе из вложенных циклов в пределах одной функции кадр стека не меняется, но по правилам языка автоматические переменные из покинутых блоков должны быть уничтожены. Компилятор генерирует для этого код вызова деструкторов и вставляет его вызовы на пути выхода из блоков. В случае stack unwinding компилятор генерирует код вызова деструкторов, но вызов этого кода происходит более сложным путём. О том, как делается stack unwinding в gcc почитать можно здесь, о том как в этот процесс встраивается вызов деструкторов -- здесь.

будет ли тоже самое для goto?

То же самое будет и для goto.

movw $0x4F02, %ax
movb $0x03, %bl
int $0x10

в bh остался мусор, а этот вызов принимает аргумент в bx.

как это сделать вместе?

Повесить второе SPI-устройство на отдельную линию CS. Я вижу, что сигнал U2RXD с разъёма P1 можно для этого использовать, если речь об этом модуле.

SRC_DIR := src/brick_game/tetris # Папка с исходным кодом

вот из этой строки нужно убрать все пробелы после слова tetris. Потому что иначе они попадают в переменную SRC_DIR. Комментарий можно оставить только впритык. Это же относится и к определениям остальных переменных.

… 75% cpu 2:23,52 total
… 113% cpu 1:22,71 total
… 73% cpu 2:20,75 total
количество потоков в программе равно количеству потоков процессора (в моём случае - 8…

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

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