jcmvbkbc

undefined reference to `boost::python::exec(char const*, boost::python::api::object, boost::python::api::object)'

Сигнатура метода не сходится:

$ c++filt 
_ZN5boost6python4execENS0_3strENS0_3api6objectES3_
boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object)

Не сконструировался boost::python::str из с-строчки.

Почему не работает данная прога?

Она на самом деле работает. Просто вывод попадает в точности на введённую строку, из-за чего непонятно, что он случился. Вот с таким изменением будет видно, что работает:

...
  call input
  mov dl, 0ah
  mov ah, 2
  int 21h
  call output
  ...

Почему можно вызвать неконстантный метод через константную ссылку?

S s;
  const S& rc = s;
  s.f();// ???????????????????????????????????????????

Ты вызываешь метод не через ссылку. Через ссылку будет так:
rc.f();
и, разумеется, это не скомпилируется.

на сегодня уже хватит программирования?

на сегодня уже хватит программирования. Речь о размере объекта (в байтах), а каждый элемент массива int наверняка занимает хотя бы 4 байта.

Вот же на картинке написано про сплошные и пунктирные стрелки: сплошная -- зависимость по коду (текст из которого выходит стрелка зависит от текста, куда стрелка втыкается), пунктирная -- зависимость по исполнению (код из которого стрелка выходит так или иначе вызывает код в который стрелка втфкается).
Треугольная стрелка -- это наследование. Класс ML1 наследуется от класса I.

Ошибка LNK2019 ссылка на неразрешенный внешний символ "public: __thiscall cd::cd(void)" (??0cd@@QAE@XZ)

говорит о том, что не найдена реализация конструктор класса cd без параметров.

Почему ядро паникует

непосредственная причина: сдох init (attempted to kill init в первой строчке), из-за сигнала (do_signal в стеке вызовов).

Упавший код:

$ echo 'Code: 0f 7f 44 17 f0 f3 0f 7f 07 c3 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 <f3> 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f' | scripts/decodecode
Code: 0f 7f 44 17 f0 f3 0f 7f 07 c3 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 <f3> 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f
All code
========
   0:   0f 7f 44 17 f0          movq   %mm0,-0x10(%rdi,%rdx,1)
   5:   f3 0f 7f 07             movdqu %xmm0,(%rdi)
   9:   c3                      retq   
   a:   48 83 fa 40             cmp    $0x40,%rdx
   e:   77 16                   ja     0x26
  10:   f3 0f 7f 07             movdqu %xmm0,(%rdi)
  14:   f3 0f 7f 47 10          movdqu %xmm0,0x10(%rdi)
  19:   f3 0f 7f 44 17 f0       movdqu %xmm0,-0x10(%rdi,%rdx,1)
  1f:   f3 0f 7f 44 17 e0       movdqu %xmm0,-0x20(%rdi,%rdx,1)
  25:   c3                      retq   
  26:   48 8d 4f 40             lea    0x40(%rdi),%rcx
  2a:*  f3 0f 7f 07             movdqu %xmm0,(%rdi)             <-- trapping instruction
  2e:   48 83 e1 c0             and    $0xffffffffffffffc0,%rcx
  32:   f3 0f 7f 44 17 f0       movdqu %xmm0,-0x10(%rdi,%rdx,1)
  38:   f3 0f 7f 47 10          movdqu %xmm0,0x10(%rdi)
  3d:   f3                      repz
  3e:   0f                      .byte 0xf
  3f:   7f                      .byte 0x7f

Code starting with the faulting instruction
===========================================
   0:   f3 0f 7f 07             movdqu %xmm0,(%rdi)
   4:   48 83 e1 c0             and    $0xffffffffffffffc0,%rcx
   8:   f3 0f 7f 44 17 f0       movdqu %xmm0,-0x10(%rdi,%rdx,1)
   e:   f3 0f 7f 47 10          movdqu %xmm0,0x10(%rdi)
  13:   f3                      repz
  14:   0f                      .byte 0xf
  15:   7f                      .byte 0x7f

судя по всему это какая-то часть memcpy или функции типа того.
Возможные причины, в порядке, кажущемся мне наиболее вероятным: баг в init либо дырявая память.

Загрузчик нормально работает при загрузке 1 сектора

Вот я собрал твой загрузчик, записал его в бут-сектор, добил двумя секторами мусора и загрузил с такого диска qemu. Выглядит так, будто бы всё работает:

$ nasm test.s -o test
$ head -c 2b /dev/urandom >> test
$ hexdump -Cv test | tail -n2
000005f0  49 93 ad 56 25 97 25 82  61 1d d9 a1 66 2a cb 19  |I..V%.%.a...f*..|
00000600
$ qemu-system-i386 -hda test -gdb tcp::1235 -S

В другом терминале, см этот ответ на вопрос "как в gdb посмотреть 16-битный код выполняющийся в qemu":

$ wget https://gist.githubusercontent.com/MatanShahar/1441433e19637cf1bb46b1aa38a90815/raw/2687fb5daf60cf6aa8435efc8450d89f1ccf2205/target.xml

Далее в том же терминале:

$ gdb
(gdb) set tdesc filename target.xml
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB.  Attempting to continue with the default i8086 settings.

(gdb) target remote :1235
(gdb) set disassembly-flavor intel
(gdb) b *0x7c32
Breakpoint 2 at 0x7c32
(gdb) c
Continuing.

Breakpoint 2, 0x00007c32 in ?? ()
(gdb) x/2i $pc
=> 0x7c32:      int    0x13
   0x7c34:      jb     0x7c3e

-- тут я остановился прямо перед командой чтения. Дальше:

(gdb) tb *0x7c34
Temporary breakpoint 3 at 0x7c34
(gdb) c
Continuing.

Temporary breakpoint 3, 0x00007c34 in ?? ()
(gdb) x/16x 0x13f0
0x13f0: 0x49    0x93    0xad    0x56    0x25    0x97    0x25    0x82
0x13f8: 0x61    0x1d    0xd9    0xa1    0x66    0x2a    0xcb    0x19

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

Ну и на экране всё мило, надпись "Loading kernel...." выводится, надпись "Kernel.bin not found!" не выводится.

Но вообще, если начать придираться, то в процедуре read_sector не инициализирован dl, так что неизвестно, с какого именно устройства происходит попытка чтения в твоём неработающем случае. Можно добавить mov dl, 80h для выбора первого ЖД, для определённости.

massiv operator=(massiv &w)

должно быть
massiv& operator=(const massiv &w)
const в параметрах -- важен.