Как может, добавляя вызов функции заставить другие символы становиться неопределенными при соединении?

Это похоже на проблему круговой ссылки на линии связи. Компоновщик просматривает объектные файлы по порядку и «запоминает» любые неразрешенные внешние объекты. Тем не менее, он также может отбрасывать любые объектные файлы, которые не имеют ссылок на них. Если два или более объектных файла ссылаются друг на друга (вызывая циклическую ссылку), компоновщик может быть не в состоянии отследить неразрешенные объекты.

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

i586-elf-ld -T link.ld -o kernel32.bin kernel_loader.o main.o stdio.o common.o gdt.o gdt_asm.o \
        stdio.o common.o gdt.o gdt_asm.o

Некая дикая догадка, возможно, ваша ассемблерная функция, которая вызывается (и, вероятно, встроена) в gdt_install, путает то, что будет после нее. (этот скачок в конце перед ret необычен, никогда не видел этого)

Ваш gdt_install находится в той же единице компиляции, что и ваш вызов? Вы используете -O[12] для компиляции? Вызван ли звонок? Как выглядит ассемблер, который создает компилятор для стороны вызова?

Вы пытались скомпилировать с помощью -O0 -g или -fno-inline (или как эта опция называется)?

Я подозреваю, что, возможно, объединение таблиц связующих символов из объекта, генерируемого носом, и объектов, генерируемых gcc / gas, может что-то испортить.

Не могли бы вы попробовать заменить вызов на gtd_install вызовом короткой встроенной функции, содержащей встроенную сборку, которая вызывает или переходит на gtd_install и находится в том же файле, что и текущий вызов на gtd_install?

Еще одна вещь, которая мне пришла в голову, это то, что если gtd_install написано на ассемблере, то возможно, что оно не будет на 100% синтаксически правильным. Я никогда не видел ничего подобного, но просто подумал, что может быть возможно, что границы gtd_install (особенно конец) или его размер не будут правильно определены ассемблером, и это просто приводит к случайным результатам.

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

Порядок файлов в командной строке, кажется, имеет значение для компоновщика GNU. Поместите файл .o , содержащий точку входа ( kernel_loader.o ), сначала в командную строку, затем все объекты, на которые он напрямую ссылается, затем объекты, на которые ссылаются эти объекты (и что еще не в строке cmd) и т. д., или возможно, что компоновщик пропустит некоторые файлы.

Есть другой вопрос SO (возможно, похожий/идентичный, я не уверен), который охватывает часть этого. Может ли этот вопрос помочь?

Я встречал похожие проблемы несколько раз, и в определенный момент, незадолго до того, как я схожу с ума, я начинаю искать невидимые вещи, которые могут оказаться в именах. Байты не-ASCII или непечатаемые символы ASCII, которые могли проникнуть в ваш исходный код и присоединиться к первому коду, увиденному после gdt_install ();

Вы можете попробовать добавить комментарий или пустой макрос (или a do {} while (0) ) между вашим вызовом gdt_install () и следующей реальной строкой кода. Может быть, даже поместите курсор в имя функции и сделайте резервную копию непосредственно перед первым символом этого имени функции и начните вводить все, что вы решите добавить туда. Если это что-то вызвано присутствием gdt_install (); , тогда что-то еще, добавленное туда, должно вызвать другую ошибку.

Если вы еще этого не сделали, вы можете просмотреть вывод препроцессора файла с помощью вызова gdt_install () , а также вывод его сборки.

Если ничего интересного не получилось, измените имя gdt_install и посмотрите, изменится ли что-нибудь. Я видел несколько случаев, когда ошибки в компиляторе и / или компоновщике могли приводить к чему-то вроде этого. Возможно, ошибка в хеш-таблице, используемой в качестве таблицы символов (возможно, даже в хеш-таблице эльфийского файла).

Надеюсь, вы в этом разберетесь.

Вы написали. " Я реализовал свои собственные функции psuedo-stdio (put, putch ...), функции точно совпадают ... " Вы используете что-нибудь в стандартной libc? В противном случае вам следует добавить -nostdlib в свою командную строку. Я видел странные вещи, когда пытался переопределить функции в стандартной библиотеке libc.