Можно прочитать про близовский формат файла

MPQ

Вроде как даже есть палёная спецификация

В том виде, в котором это сформулировано задача довольно сложная. Все современные компиляторы пытаются её решить хотя бы приближённо. Чтобы можно было в отладчике поставить breakpoint нужно отображение "стока в исходном коде -> инструкция". Чтобы можно было остановиться по произвольному событию (watchpoint переменной) и понять где сейчас находится поток управления, нужно обратное отображение. Оба отображения неоднозначны: в первом случае когда одна операция в исходном коде дублируется в несколько операций в машинном коде (unrolling, unswitching, jump threading, и т.п.), во втором случае - наоборот (устранение общих подвыражений, tail merging).

В LLVM есть некоторая документация на эту тему https://llvm.org/docs/SourceLevelDebugging.html
Общий принцип, насколько я понимаю, простой: из исходного кода генерируется LLVM IR, где к каждой инструкции прикреплена информация о позиции в исходном коде. Оптимизации и backend пытаются по возможности эту информацию сохранить, а при вставке новых инструкций выбрать другую инструкцию, откуда эту информацию скопировать.

Одна интересная идея/статья на тему от разработчиков GCC: https://developers.redhat.com/blog/2017/07/11/statement-frontier-notes-and-location-views/

Самый распространённый открытый формат отладочной информации - это DWARF, там в разделе про "Line Number Information" описан формат.

godbolt красиво подсвечивает :) но это всё приблизительно при агрессивных оптимизациях

а при отладке разве делаются оптимизации?

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

наврал Gemstone

Почитал. Это формат архива, то есть там внутри в конечном счёте после распаковки и расшифровки будут файлы в различных форматах, которые MPQ рассматривает как чёрный ящик и то, как трактовать их решает приложение на основе его типа.
Я продумываю такой формат, который не содержит никаких чёрных ящиков и знает, какие данные он содержит вплоть до каждого пикселя изображения и вершины 3D модели и т.п.. Допустим, если файл хранит все данные игры, то можно будет подгрузить его, а потом написать

DataVoln::OpenFile("game.bdv").DeserializeExpr<Color>("Levels.MyLevelName.Textures.Metal.Pixels[42][42]");

И это выражение прочитает цвет пикселя текстуры с именем Metal, находящейся в уровне с именем MyLevelName в позиции x = 42, y = 42. И будет выполнен ровно тот объём вычислений, который нужен. То есть весь файл не будет расжиматься и декодироваться, если его структура позволяет прочитать данные пикселя без распаковки всего.
То есть никаких вложенных JPG/PNG/DDS, всё делается средствами одного формата.

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

DataVoln::OpenFile("game.bdv").DeserializeExpr<Color>("Levels.MyLevelName.Textures.Metal.Pixels[42][42]");

https://en.wikipedia.org/wiki/Apache_Parquet
https://en.wikipedia.org/wiki/Apache_Avro
? Есть и ещё подобные проекты...

DataVoln::OpenFile("game.bdv").DeserializeExpr<Color>("Levels.MyLevelName.Textures.Metal.Pixels[42][42]");

Там если что мета есть, и это не черный ящик

Закинуть в мету рантайм - и вот что ты хотел

В теории: В DWARF описана виртуальная машина, отладочная информация для переменной будет представлять собой код для этой VM, вычисляющий значение переменной исходя из доступных значений. На практике это, во-первых, не всегда возможно, а во-вторых разработчики оптимизаций часто на это просто забивают. Так что оптимизатор всегда делает одни и те же преобразования, независимо от наличия отладочной информации, при это часть отладочной информации может теряться. В GDB вы увидите вместо значения переменной <optimized out>.

о как, не знал

Пополню ими список того, что "убьёт" моя технология. Всё что существует - avro, parquet, protobuf, flat buffers, json, xml и т.п. вместе взятое покрывает от силы 10% того функционала, который будет в моём формате-языке. У меня будут:
1) Поля произвольной битности. Например, можно хранить монохромные картинки без оверхеда и кастомной логики на стороне приложения
2) вычисляемые поля - был сначала формат с полями A и B, в новой версии поле A убрали, ввели C и указали, что A = C*2. Старая версия программы сможет прочитать новый файл. Новая версия сможет прочитать старый файл. Совместимость в обе стороны. Или, к примеру, можно не хранить пиксели изображения совсем, а записать формулу вычисления каждого пикселя картинки. Программа сможет прочитать этот файл как картинку, не имея представления о том, хранится ли она в файле или считается по формуле.
3) формат можно использовать как язык для обработки данных - писать всякие map, reduce, filter, считать статистические функции над данными и делать другую обработку.
Вот такая идея. Большую часть уже продумал и выглядит, что это вполне реально сделать силами одного человека и умениями, которые у меня уже есть. Жду не дождусь, когда руки дойдут до реализации.

Т.е. Вы переизобретаете SQLite? 😃

Хрень. Все это уже есть в том или ином виде.

А также этот язык можно транслировать в С и обратно, и компиляция Doom 3 занимает 0.4 секунды?

Не вижу причин использовать то что вы предлагаете в третьем пункте, когда то же самое и даже больше предоставляет питон с scipy/numpy