jcmvbkbc

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

непосредственная причина: сдох 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 в параметрах -- важен.

You have unstaged changes.

Закоммитить, внести в stash или удалить несохранённые изменения.

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

в чём угодно. Никакой полезной информации для её диагностирования в твоём вопросе не содержится.
Минимально полезным был бы стектрейс крэша.

Как вызвать из C++ программы функции на ассемблере?

extern "C" void number1();
…
int main()
{
number1();
}

Именно так.

dch -v $$VERSION
должно работать.
Потому что

export VERSION=$(shell read -p "Version: ";echo $$REPLY)

экспортирует переменную внутри shell, а $(VERSION) ссылается на переменную make а не на переменную shell.

Как вариант, подойдет `make dchv 1.3.4` , но научить makefile такое делать - лютый геморрой :(

не нужно этого делать, потому что это "против шерсти". Правильнее было бы сделать так: make dchv VERSION=1.3.4 и выкинуть код по вводу переменной VERSION из правила dchv, т.е. оставить только dch -v $(VERSION)

error C2664: "int system(const char *)": невозможно преобразовать аргумент 1 из "std::basic_string,std::allocator>" в "const char *"
как можно исправить этот баг

system((zi + path).c_str());

Как я могу обойти эту ошибку и свободно создавать экземпляр ENUM в любых заголовках?

Подключив заголовок с определением типа перед использованием этого типа.

16

int a(10); // работает
MyStruct b(); // не работает

смотри, я пофиксил твой кейс:

int a(); // не работает
MyStruct b(); // не работает

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

int a(10); // работает
MyStruct b(10); // работает

если завести у MyStruct конструктор с целочисленным параметром.
Если серьёзно, то в чём проблема-то?

Я уже просто испробовал много способов,но никак не дебажется.

вот тебе цикл, который считает слова в файле fin, не расстраивайся:

int z = 0;

while (fscanf(fin, "%*s") == 0)
    ++z;