Как вы отлаживаете двоичный формат?

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

Похоже, что вы можете просматривать двоичный файл в разных вариантах (в моем случае я хотел бы видеть его в 8-битных кусках как десятичные числа, потому что это довольно близко к вводу). На самом деле, некоторые числа 16-разрядные, некоторые 8, некоторые 32 и т. Д. Поэтому, возможно, был бы способ просмотреть двоичный файл, в котором каждое из этих различных чисел каким-то образом выделено в памяти.

Единственный способ увидеть это возможно, если вы действительно создадите визуализатор, соответствующий конкретному двоичному формату / макету. Таким образом, он знает, где в последовательности должны быть 32-разрядные числа, а также где должны быть 8-разрядные числа и т. Д. В некоторых ситуациях это очень трудоемкий и сложный процесс. Так интересно, есть ли общий способ сделать это.

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

Для специальных проверок, просто используйте стандартную hexdump и научитесь смотреть на нее.

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

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

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

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

Поиск в Google для языка схемы двоичных данных включает в себя ряд инструментов. Примером является Apache DFDL . Для этого уже может быть пользовательский интерфейс.

ASN.1 , Абстрактная синтаксическая нотация 1, предоставляет способ указания двоичного формата.

• ДДТ - Разработка с использованием образцов данных и модульных тестов.
• Текстовый дамп может быть полезным. Если в XML вы можете свернуть / развернуть иерархии.
• ASN.1 на самом деле не нужен, но на основе грамматики более декларативная спецификация файла проще.

Другие ответы описывают просмотр шестнадцатеричного дампа или написание структур объектов в JSON. Я думаю, что объединение обоих из них очень полезно.

Использование инструмента, который может визуализировать JSON поверх шестнадцатеричного дампа, действительно полезно; Я написал инструмент с открытым исходным кодом, который анализировал двоичные файлы .NET под названием dotNetBytes , вот пример библиотеки DLL .

Я не уверен, что полностью понимаю, но, похоже, у вас есть парсер для этого двоичного формата, и вы управляете кодом для него. Таким образом, этот ответ построен на этом предположении.

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

Вы бы по существу имели:

byte[] arrayOfBytes; // initialized somehow
Object obj = Parser.parse(arrayOfBytes);
Logger.log(obj.ToString());

И это все, с точки зрения его использования. Конечно, это требует от вас реализации / переопределения ToStringфункции для вашего Objectкласса / структуры / чего бы то ни было, и вам также придется делать это для любых вложенных классов / структур / whatevers.

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

Вы ToStringможете выглядеть так:

return String.Format("%d,%d,%d,%d", int32var, int16var, int8var, int32var2);

// OR

return String.Format("%s:%d,%s:%d,%s:%d,%s:%d", varName1, int32var, varName2, int16var, varName3, int8var, varName4, int32var2);

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

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

Аналогичным образом: некоторые языки имеют надежные функции для преобразования классов в XML или JSON. C # особенно хорош в этом. Вам не нужно отказываться от своего двоичного формата, вы просто делаете XML или JSON в операторе ведения журнала отладки и оставляете свой код выпуска в покое.

Я лично рекомендую не идти по маршруту шестнадцатеричного дампа, потому что он подвержен ошибкам (вы начали с правого байта, уверены ли вы, когда читаете слева направо, что «видите» правильный порядок байтов и т. Д.) ,

Пример. Скажите, что вы ToStringsвыплевываете переменные a,b,c,d,e,f,g,h. Вы запускаете свою программу и замечаете ошибку g, но проблема действительно началась с c(но вы отлаживаете, так что вы еще не поняли). Если вы знаете входные значения (и должны это сделать), вы сразу же увидите, что cименно здесь начинаются проблемы.

По сравнению с шестнадцатеричным дампом, который просто говорит вам 338E 8455 0000 FF76 0000 E444 ....; если ваши поля различаются по размеру, где cначинается и каково значение - шестнадцатеричный редактор скажет вам, но я хочу сказать, что это подвержено ошибкам и требует много времени. Не только это, но вы не можете легко / быстро автоматизировать тест с помощью шестнадцатеричной программы просмотра. Распечатка строки после анализа данных точно скажет вам, о чем думает ваша программа, и станет одним из шагов на пути автоматического тестирования.