Как мне правильно считать дескрипторную таблицу?

Question

[Типа Программист]

Пишу свое ядро на Си, и ассемблере.
Для сборки "проекта: "использовал скрипты из данной статьи https://xakep.ru/2018/06/18/lets-write-a-kernel/

Проблема заключалась в том что когда я запускал ядро в qemu через ключ -kernel, все работало отлично, но запуская через easyBCD на реальном железе, исчез весь весь текст, и вовсе оно слегка поломалось.
Случайно выяснил что дело в дескрипторной таблице, когда я менял селектор на сегмент кода для шлюза прерывания, то код начинал работать на реальном железе но в тот-же момент прекращал работать на виртуалке.

Решил что просто задам свою дескрипторную таблицу ( хотя-бы попытаюсь ), и первым делом решил её считать, используя код ниже получил адрес таблицы, в качестве аргумента передавал указатель на структуру ( структуры ниже.

_getGDTR:
mov eax,[esp+4]
sgdt [eax]
ret

И когда я считал сегменты, я получил какой-то мусор, причем даже когда я решил перезаписать их значениями 0xFF, произошло НИЧЕГО, код выполнился дальше, на экране я получил вывод, так будто-то бы я и не затронул никакой важной информации.

Пример того что лежит в дескрипторах ( что в нулевом, что в следующем, итд там различий не много )


У меня есть догадка насчет того что мой сегмент кода\данных не покрывает полностью 4 гига, и мои обращения по адресу получаются смещены из за смещения самого сегмента. Но я не уверен, может я где-то накосячил.

Структуры в Си коде:

struct GDTR{
    unsigned short limit;
    unsigned long addr;
};

struct SegmentDescription {
	unsigned char limit_low_low;
	unsigned char limit_low_hi;
	unsigned char	address_low_low;
	unsigned char	address_low_hi;
	unsigned char address_middle;		
	unsigned char access_rights;		
	unsigned char limit_hi_and_flags;
	unsigned char address_hi;	
};

Так-же приложу дамп памяти по "адресу"( я не уверен что это действительно дамп с нужного адреса ) таблицы:


Буду рад любым подсказкам.

Comments

[jcmvbkbc]

Буду рад любым подсказкам.

Ты, может, свой код покажешь?

[Типа Программист]

jcmvbkbc, оказалось что проблема немного не там. Что-то не так с самой первой структурой:

struct GDTR{
    unsigned short limit;
    unsigned long addr;
};

Поле адреса дает не верные значения. Но если заменить unsigned long, на структуру такого вида:

struct u32{
	unsigned char byte1;
	unsigned char byte2;
	unsigned char byte3;
	unsigned char byte4;
};

То сделав вот так *(unsigned int*)&currentGDTR.addr, я получаю верное значение. Проверял sizeof(long), равно 4, а sizeof(short), равно 2

[Типа Программист]

Код который работает с костылем описанным выше:

// Точка входа
void kmain(){
	struct GDTR currentGDTR;
	getGDTR(&currentGDTR); 
	putLine("  ADDRESS: ");
	putDecUI(*(unsigned int*)&currentGDTR.addr);
}

Функции на ассемблере:

bits 32
section .text

global _getGDTR
_getGDTR:
mov eax,[esp+4]
sgdt [eax]
ret

Структуры на Си:

struct u32{
	unsigned char byte1;
	unsigned char byte2;
	unsigned char byte3;
	unsigned char byte4;
};

struct GDTR{
    unsigned short limit0;
	struct u32 addr;
};

void getGDTR(struct GDTR* ptrGDTR );

Answer 1

[Типа Программист]

Вероятнее всего проблема связана с тем как компилятор Си упаковывает структуры.

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

Подробнее:
https://m.habr.com/ru/post/142662/

PS: Сам задал вопрос, сам ответил. Помечать ответ не буду, как-то не красиво получается, да и я не уверен что я прав. Но мне вроде помогло, используя знания из ссылочки выше, смог сделать работающий костыль ( удача? ).

Comments

[jcmvbkbc]

я не уверен что я прав.

Да не, похоже, что прав. Поля в структуре GDTR лежат не по естественному выравниванию, поэтому компилятор С вставит паддинг. Вместо твоего костыля можно применить #pragma pack или __attribute__((packed)) к исходному определению твоей структуры.