jcmvbkbc

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

Правильно.

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

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

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

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

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

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

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

Чтобы она запускалась -- её нужно скомпилировать, у тебя пока проблема с этим.

push ax dx
...
pop dx ax

tasm так не умеет, вроде. Если хочешь положить несколько регистров на стек -- пиши push для каждого регистра по отдельности.

Почему у меня при отладке (картинка 1), и при чужой отладке (картинка 2) в сегменте, внизу, где четыре строки es, значения совершенно отличаются, хотя это отладка одной и той же программы?

Мария, потому что память заполнена по большому счёту мусором. es в твоей программе не инициализирован, непонятно зачем ты на него смотришь. Надо смотреть на ds. В твоём отладчике Max находится по адресу 57ef:000a

;1 вариант
mov ah,02h
int 1Ah
inc cl
mov ah,06h
int 1Ah;

Мы получаем текущее время, прибавляем к минутам единицу и настраиваем будильник (случаи, когда 59 минут можно не рассматривать)

Время из int 1Ah возвращается в BCD. Чтобы увеличить счётчик минут на 1 inc cl недостаточно, нужно mov al, cl ; inc al ; daa ; mov cl, al.

как только ноты заканчиваются, DOS перестает на что либо реагировать

а зачем ты вызываешь void когда ноты заканчиваются?

я хочу поместить метку "L0" в регистр %rbx.
relocation R_X86_64_32S against `.text' can not be used when making a shared object

Если это локальная метка -- то по смещению от PC:
leaq L0(%rip), %rbx
Если это метка из другой динамической библиотеки -- то через plt:
movq L0@gotpcrel(%rip), %rbx

Сначала идёт команда 7A - погасить лампочку. Команда загружает в регистр R0 число 2. Почему?

Поскольку у тебя P = 0, то R(0) используется как program counter. Инструкция 7А должна его увеличить на 1, т.е. после неё в R(0) должно быть 1.

Далее идёт команда F8 Описание этой команды M(R(P)) → D; R(P) + 1 → R(P)
Команда F8 загружает в регистр F8 число 3, хотя команда, судя по описанию, должна прибавлять к регистру R0 число 1 и сохранять результат в R0, значит в R0 должно оказаться число 1.

Нет, не так. Сначала команда загружается в регистры I и N, а R(0) увеличивается на 1. После этого достаётся байт из памяти по адресу R(0) и помещается в D, а R(0) увеличивается ещё на 1.

Дизассемблированная программа:

0: 7A -- reset Q (Q = 0)
1: F8 -- ldi 10 (D = 10)
2: 10
3: B1 -- phi 1 (R(1).1 = D, т.е. R(1) = 1000)
4: 21 -- dec 1 (R(1) = R(1) - 1, т.е. R(1) = fff)
5: 91 -- ghi 1 (D = R(1).1, т.е. D = f)
6: 3A -- bnz 4 (переход к адресу 4, пока D != 0)
7: 04
8: 31 -- bq 0 (переход к адресу 0 если Q == 1)
9: 00
a: 7B -- set Q (Q = 1)
b: 30 -- br 1 (переход к адресу 1)
с: 01
d: 00 -- idle (никогда не попадаем сюда).

В середине просто цикл задержки на счётчике.

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

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

что не так?

В видеорежиме 100h нет гарантии, что вся видеопамять доступна одним непрерывным куском. И если вызвать функцию 0x4f01 прерывания 0x10, то она вернёт структуру, в которой указан размер окна. Мне она возвращает 64К (0x40), что существенно меньше 640 * 400 = 256000:

0x7c00:      mov    $0x4f01,%ax
   0x7c03:      mov    $0x100,%cx
   0x7c06:      mov    $0x7c77,%di
   0x7c09:      int    $0x10
(gdb) x/6hx $di
0x7c77: 0x00bb  0x0007  0x0040  0x0040  0xa000  0x0000

Чтобы обратиться к остальной видеопамяти, нужно либо переключать банки видеопамяти функцией 0x4f05, либо как-то включать линейный доступ к видеопамяти.

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

По многим причинам:
- ты забыл загрузить ds и es после перехода в защищённый режим
- тебе нечем их загрузить, поскольку в gdt нет сегментов доступных для записи
- адрес видеопамяти -- 0xa0000, а на 0xa000 как у тебя

Вся проблема в том что не понимаю я структуры дескриптора..

https://en.wikipedia.org/wiki/Global_Descriptor_Table в чём сложность?

db 0xFF, 0xFF, 0x00, 0x00, 0x00, 10011010b, 11001111b, 0x00

Segment limit: 0xfffff
Base address: 0x00000000
Type: 0xa
S: 1
DPL: 0
P: 1
A: 0
DB: 1
G: 1
Т.е. этот сегмент действительный (P = 1), не системный (S = 1), начинается с адреса 0, покрывает 4Г, исполняемый и доступный для чтения (Type = 0xa), доступен из кольца защиты 0 (DPL = 0), не читанный (A = 0), со страничной гранулярностью (G = 1).

Я не могу понять именно как происходит этот прыжок

jmp 00001000b:pm_entry
use32
pm_entry:

В cs попадает 0x8, т.е. CPL = 0, использовать 1ю запись в GDT, в pc -- pm_entry.

- старое архитектурно-специфичное представление (определения в arch/*/include/uapi/asm/unistd.h, на примере MIPS)
- старое архитектурно-независимое представление (определения в include/uapi/asm-generic/unistd.h, ими пользуется, например, ARM64)
- новое представление (отдельный файл определений из которого генерируются заголовочные файлы),

Мне дан файл input.txt, в котором находится строка, где через пробел указаны числа (их число неизвестно). Требуется узнать их сумму.
...
мне кажется, что тут всё запутано и можно легче. Подскажите как.

не заводить промежуточных массивов, считать всё на лету:
0) нужно держать текущую сумму (S), инициализировать её нулём
1) нужно держать значение прочитанного на данный момент числа (V), инициализировать его нулём
2) читать из файла посимвольно
-- если прочитанный символ -- цифра (d), добавить её к текущему числу: V = V * 10 + d
-- если прочитанный символ -- не-цифра или конец файла, добавить текущее число к сумме и занулить текущее число: S = S + V; V = 0
3) если конец файла, то вывести S и закончить работу, иначе продолжить с п. 2