SBCL-1.0.42

[dmitry_vk]

Собрал виндовый инсталлятор SBCL 1.0.42 (раньше использовал 1.0.40) с поддержкой нитей.

https://sites.google.com/site/dmitryvksite/sbcl-distr/sbcl-1.0.42-threads.msi

Comments

[dmitry-vk.livejournal.com]

1. Поздно заметил. Да, результат должен быть одинаковым.
3. Как я понимаю, в "холодной" фазе сборки просматривается не все внешние символы. Я не разбирался с этим, но в win32-os.c есть функция scratch (нигде не вызываемая), в которой вызываются с нулевыми параметрами все функции, используемые рантаймом.

[akovalenko.livejournal.com]

[На всякий случай]:

В холодной фазе SBCL знает те символы, что попали в вывод nm. А вот в вывод nm они попадают так: вызов функции из scratch() заставляет линкер подключить кусочек import library, в котором находится трамплин, вот такой:
;; это в .text
_Sleep@4: jmp [__imp_Sleep@4]
..где __imp_Sleep@4 разрешается (при сборке PE Executable) в то место в .idata, куда попадает адрес настоящей функции из DLL.

Из потенциально-интересного нормальному человеку:
1. Механизм сломается на функциях, объявленных как __declspec(dllimport): при этом в точку вызова сразу компилируется косвенный вызов jmp [__imp_blabla], а трамплин отсутствует.
2. Поздняя привязка через LL/GPA дешевле на один трамплин + один косвенный вызов
3. Хорошей идеей представляется выпиливание всех этих собачьих суффиксов из sbcl.nm или при его парсинге. Вроде ничего не теряем, а получаем избавление от низкоинтеллектуальной деятельности (что подсчёт аргументов, что поиск функции в nm...) плюс лучшую переносимость на 64 бита (когда CloseHandle@4 внезапно становится просто CloseHandle, из-за того, что про ABI для платформы подумали заранее).

[akovalenko.livejournal.com]

3+. Сделал в виде "искать статические символы как по имени с @N, так и без него". Собирается. Работает. Закоммитил.