mjhjmtu

I would like to be able to debug building a binary builder. Right now I am basically printing out the input data to the binary parser, and then going deep into the code and printing out the mapping of the input to the output, then taking the output mapping (integers) and using that to locate the corresponding integer in the binary. Pretty clunky, and requires that I modify the source code deeply to get at the mapping between input and output.

It seems like you could view the binary in different variants (in my case I'd like to view it in 8-bit chunks as decimal numbers, because that's pretty close to the input). Actually, some numbers are 16 bit, some 8, some 32, etc. So maybe there would be a way to view the binary with each of these different numbers highlighted in memory in some way.

The only way I could see that being possible is if you actually build a visualizer specific to the actual binary format/layout. So it knows where in the sequence the 32 bit numbers should be, and where the 8 bit numbers should be, etc. This is a lot of work and kind of tricky in some situations. So wondering if there's a general way to do it.

I am also wondering what the general way of debugging this type of thing currently is, so maybe I can get some ideas on what to try from that.

For ad-hoc checks, just use a standard hexdump and learn to eyeball it.

If you want to tool up for a proper investigation, I usually write a separate decoder in something like Python - ideally this will be driven directly from a message spec document or IDL, and be as automated as possible (so there's no chance of manually introducing the same bug in both decoders).

Lastly, don't forget you should be writing unit tests for your decoder, using known-correct canned input.

The first step to doing this is that you need a way to find or define a grammar that describes structure of the data i.e. a schema.

An example of this is a language feature of COBOL which is informally known as copybook. In COBOL programs you would define the structure of the data in memory. This structure mapped directly to the way the bytes were stored. This is common to languages of that era as opposed to common contemporary languages where the physical layout of memory is an implementation concern that is abstracted away from the developer.

A google search for binary data schema language turns up a number of tools. An example is Apache DFDL. There may already be UI for this as well.

ASN.1, Abstract Syntax Notation One, provides a way of specifying a binary format.

• DDT - Develop using sample data and unit tests.


• A textual dump can be helpful. If in XML you can collapse/expand subhierarchies.


• ASN.1 is not really needed but a grammar based, more declarative file specification is easier.

Other answers have described viewing a hex dump, or writing out object structures in i.e. JSON. I think combining both of these is very helpful.

Using a tool that can render the JSON on top of the hex dump is really useful; I wrote an open source tool that parsed .NET binaries called dotNetBytes, here's a view of an example DLL.

I'm not sure I fully understand, but it sounds like you have a parser for this binary format, and you control the code for it. So this answer is built on that assumption.

A parser will in some way be filling up structs, classes, or whatever data structure your language has. If you implement a ToString for everything that gets parsed, then you end up with a very easy to use and easily maintained method of displaying that binary data in a human readable format.

You would essentially have:

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

And that's it, from the standpoint of using it. Of course this requires you implement/override the ToString function for yourObject class/struct/whatever, and you would also have to do so for any nested classes/structs/whatevers.

You can additionally use a conditional statement to prevent the ToString function from being called in release code so that you don't waste time on something that won't be logged outside of debug mode.

Your ToString might look like this:

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);

Your original question makes it sound like you've somewhat attempted to do this, and that you think this method is burdensome, but you have also at some point implemented parsing a binary format and created variables to store that data. So all you have to do is print those existing variables at the appropriate level of abstraction (the class/struct the variable is in).

This is something you should only have to do once, and you can do it while building the parser. And it will only change when the binary format changes (which will already prompt a change to your parser anyways).

In a similar vein: some languages have robust features for turning classes into XML or JSON. C# is particularly good at this. You don't have to give up your binary format, you just do the XML or JSON in a debug logging statement and leave your release code alone.

I'd personally recommend not going the hex dump route, because it's prone to errors (did you start on the right byte, are you sure when you're reading left to right that you're "seeing" the correct endianness, etc).

Example: Say your ToStrings spit out variables a,b,c,d,e,f,g,h. You run your program and notice a bug with g, but the problem really started with c (but you're debugging, so you haven't figured that out yet). If you know the input values (and you should) you'll instantly see that c is where problems start.

Compared to a hex dump that just tells you 338E 8455 0000 FF76 0000 E444 ....; if your fields are varying size, where does c begin and what's the value - a hex editor will tell you but my point is this is error prone and time consuming. Not only that, but you can't easily/quickly automate a test via a hex viewer. Printing out a string after parsing the data will tell you exactly what your program is 'thinking', and will be one step along the path of automated testing.