OberonCore

Это очень хитрая ошибка, два дня искал. Флюктуации миграции в сторону BlackBox/CPfront.
Связана с подсчётом количества методов, который в Ofront и в BlackBox устроен по-разному.
Под список методов выделялся массив меньшего размера, чем требовалось, что приводило к порче памяти.
Исправил.

Коллеги, у кого-нибудь здесь есть опыт низкоуровневого программирования под Linux, Windows? Такие дела. Недавно в voc/Ofront+ была найдена и исправлена ошибка в сборщике мусора. И, как оказалось, сборщик мусора вообще был незадействован. После фикса, который просто сводился к убиранию "творчества" Дэйва Брауна, я вернулся к тому же коду, что в оригинальном Ofront. И сборщик заработал, однако после пересборки самого себя транслятор стал в некоторые моменты трапиться. Отладка показала, что это происходит в момент взятия данных из стека. На стеке, как мы знаем, хранятся локальные переменные. И консервативный сборщик шпарит по ним, собирая указатели простым сравнением со списком уже выделенных указателей.

Вопрос такой: можно ли предположить, что если даже читать память из области стека, то будет приходить какой-то сигнал, прерывание или исключение? Если я прав, значит нужен обработчик, который не будет делать ничего. У кого-нибудь есть опыт подобного? Спасибо.

На самом деле сложно понять, из-за чего именно трапится.
Есть два варианта:
- возможно, что срабатывает какой-то внутренний ASSERT в сборщике мусора;
- или система запрещает обращение по какому-то адресу.
Под стек на windows обычно выделяется что-то типа 10 Мб. Соответственно, обращаться к стеку можно по адресам от начального, то конечного. Соседние страницы памяти могут быть не выделены и при попытке к ним обратиться может возникать исключение.
Теоретически, возможна ситуация, что не ко всем страницам внутри определенного интервала можно обращаться, они могут быть выделены для других целей (антивирус, вирус, драйвер и т.д., может загружаться внутрь адресного пространства и занимать там какую-то область). По-хорошему, нужно учитывать такие моменты, что может быть не сплошной кусок памяти, а с разрывами (для стека это не очень актуально, а для выделения динамической памяти в куче это может быть актуально).

Я бы сделал так:

1. Знать, где находится стек.

2. Знать, где находится куча.

3. В сборщике мусора не пытаться разыменовывать те "указатели", которые указывают ни на стек, ни на кучу. Тогда и исключений не будет. Исключения, мало того, что требуют обработчика, так ещё и их обработка занимает время.

Если же сделать обработчик исключения, который ничего не делает, то этот обработчик скроет также и реальные ошибки в сборщике мусора, и разные повреждения памяти.

Хотя, поглядев на код...
Например, можно проверить версию о том, что логика сборщика неправильная и он пытается читать за пределами стека... И ещё неплохо бы понять, что именно делает GET

Да, действительно. Сборщик пытался читать за пределами стека.

__GET это же SYSTEM.GET. Читает из памяти по указанному адресу в переменную.

Проблема со сборкой мусора исправлена. Надеюсь, теперь уже окончательно.

Дмитрий Викторович, я сейчас вот накатил Ваш патч и столкнулся с такой проблемой:


Раньше сгенерированный для этого модуля код выглядел так:
А после патча выглядит так:

И такой хедер не хочет включаться, т.к. в нём не определено OPP__1.

Ваша правка в DevCPC.DefineType. Было:
Стало:

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

Тут наложились мои эксперименты с динамической загрузкой (пока еще не доделанной) и привязкой загружаемых модулей. Даже, если тип неэкспортирован, тэг типа нужен.

На всякий случай прогнал свои 479 тестов с Вашей правкой и без - все совпадает для статически собираемых модулей.

Да, CPfront генерирует код с этой правкой несколько другой, нежели Ofront+
В том плане, что для вышеприведённого модуля описание типа OPP__1 в хедере генерится.

Как успехи с динамической загрузкой? Вы ведь через стандартный механизм ОС .so/.dll делаете?

Реализована для бэкенда LLVM в первой версии. Для CPfront-бэкенда Omf пока в работе. Грузятся объектники в coff и elf формате https://forum.oberoncore.ru/viewtopic.php?f=157&t=6423&start=20#p112043. Выставлена версия 0.95.

Это я видел, я же читаю форум. Не, именно для CPfront интересно.

Я делал динамическую загрузку модулей через dlopen. Работает, но допилить cpfront надо. (секция CLOSE не регистрируется в дескрипторе модуля).

Немного забыл про этот форум. Новостей много, но основные:

1. Наконец-то сделан корректный экспорт константных массивов

2. Артур Ефимов заявил о переводе Free Oberon на ядро Ofront+

3. Ofront+ показывает себя стабильным продуктом. В последнее время совсем мало правок. Конечно в планах ещё много всего, но пользовать уже очень можно.

А Вы не думали/пробовали в Ofront+ делать константные структуры произвольного содержания?

Поясню. Если мы посмотрим на С-код, сгенеренный Ofront'ами, то там огромное число таких структур, например

И, что важно, эти структуры ложатся при загрузке в секцию данных, а не в секцию кода.
А в Обероне такого нет. И что, получается, мы не сможем такое сделать на Обероне?

Такие запросы от юзеров были. Но решили не усложнять язык.
Если доберётесь сделать, будет интересно посмотреть синтаксис.

Ну да, получается, не сможем. Разве что в Ofront'е через уровень Си.