Add option to build and use uncompressed *.sla files

[jobermayr]

An uncompressed *.sla file was and is easier for development and to debug.
Please add an option to build and use uncompressed files after 8fbd171 again.
Maybe sla<version>u and sla<version>c at beginning could mark whether (un)compressed.

[ryanmkurtz]

Can you please expand on your development and debug workflow? We are wondering why you are directly working with the .sla files. What problem is that solving for you?

[jobermayr]

I am trying to debug failure in https://github.com/jobermayr/ghidra-staging/blob/master/4812-Introduce-operand-offset-C-and-Java.patch. I don't know whether Native, Java or both lead to the error when loading a vax file on Java side. When trying to inspect the sla file whether tags are mismatched I only see "hieroglyphs".
I also tried to decompress but failed because it looks like each "tag" is compressed. Maybe it would be enough to compress only once after sla<version> so all tags are visible then. So people can easily build an decompressor for manual inspection ...

[ghidracadabra]

Note that you can generate the old XML format using the native sleigh compiler with the -y option. Ghidra can't use them, but you can inspect them manually for debugging.

[dev747368]

You can see the uncompressed payload by doing some hackery like:

{ printf "\x1f\x8b\x08\x00\x00\x00\x00\x00"; dd if=x86.sla bs=1 skip=4; } | zcat

This puts enough of a gzip header at the start of the compressed data to let zcat work. You will still get a warning when it hits eof though.

It will let you see the new binary (non-xml) representation and some of the strings embedded in the data.

[ryanmkurtz]

@jobermayr, to touch base on this, it sounds like you can use the -y option to see the generated sleigh to solve the first half of your problem. As for the 2nd half of the problem (Ghidra actually being able to use the uncompressed format), the team discussed it and decided that this will not be supported anymore.