Beginner questions

[djhenderson]

I build the common hello world program in C and compiled it on MSYS2. I have been trying to use Reko with it as an exercise.

1. When I select "Mark Type" from the context menu, a small edit box opens, however it is not clear what to enter. When I enter something and press ENTER, I usually get an exception, and when I press TAB nothing seems to happen.
2. I do not know how to add a label or name to data. I do know how to change the name of a procedure, but it is very useful to change data names.
3. When I examine the C source in the .h and .c files, there seem to be some macros for which I cannot find any definitions: e.g. CONVERT, SLICE.
4. When I select File->Exit, I am not prompted to save the current project, even though I have made changes.
5. I tried to make a metadata file named meta1.meta, but Reko tried to open as a binary file.

I'm a Python programmer these days; my C and C++ is very rusty now, and I'm not ready to dive into C# yet, but at some point I may have to. I might be more productive writing python scripts.

TIA

[WolfeComputerServices]

How do I compile the C code generated. I've tried VS2022 using the legacy, 2011, and 2017 standards. I've also tried gcc (via CodeBlocks) using the C99 standard. However, they all generate 1000's of errors. I wouldn't expect it to be perfect "right out the box" (so to speak), but it seems way off. What is the recommended way of compile the C code generated using Reko?

Reko Version 0.11.4.0 (64-bit)
Running on Windows 11
Decompiling DOS 16-bit EXE

Any suggestions are greatly appreciated.

[ptomin]

Reko (and any other decompiler) output code is not supposed to be compiled. You can manually edit the code though.

[uxmal]

Unfortunately, the state of the art in decompilers today is not advanced enough to make the output immediately compileable. It will require some serious massaging. This is a well-known limitation, arising from the fact that the compilation is a lossy process, and a lot of information is lost when compiling that decompilers just cannot reconstruct on their own.

What you can do, however, is assist the decompiler by providing it with metadata. That is, type information about data and executable code ("function fn00123400 takes a char * parameter and returns an int"). By doing so, and providing Reko with the insight of your human intelligence, the output is vastly improved.

That said, MS-DOS 16-bit EXE will prove to be quite challenging to get compile with a modern compiler. Those programs, if not written in assembler, Pascal, or other languages popular in the 1980's and 1990's, were written in a dialect of C extended to support the segmented memory model of the x86 processors used at the time. These extensions aren't standard C at all, and modern compilers will refuse to compile them. Reko doesn't attempt to generate such non-standard C yet, although it is a commonly requested feature.

For the time being, my recommendation is to tell Reko about the data types of your procedures and memory locations, and let that information guide it. You will obtain clearer output that will make more sense to you, and perhaps even be compile-able in fragments.

[uxmal]

@djhenderson : Sorry for the very late response. I didn't receive a notification from GitHub about your query, and was unaware of its existence until others pointed it out to me. I hope to be more responsive in the future!

I build the common hello world program in C and compiled it on MSYS2. I have been trying to use Reko with it as an exercise.

When I select "Mark Type" from the context menu, a small edit box opens, however it is not clear what to enter. When I enter something and press ENTER, I usually get an exception, and when I press TAB nothing seems to happen.

The Mark Type command lets the user dictate the data type of a range of memory addresses. When you execute the command, the edit box allows free-form entry of a data type that you wish the selected memory to have. When I wrote this feature, Reko didn't have a C parser. Instead I used "systems Hungarian" as a stopgap (as well as a an accelerator). Here are some examples (taken from the source code https://github.com/uxmal/reko/blob/master/src/Gui/HungarianParser.cs):

ai32           (array of 32-bit signed integers)

aiw        (array of 32-bit signed integers -- same as above)

au16        (array of 16-bit unsigned integers)

ab        (array of bytes)

ach buf    (array of 8-bit characters named ‘buf’)

a100wch    (array of 100 16-bit characters)

ax100wch    (array of 256 16-bit characters)    

pch        (pointer to 8-bit characters)

pfn __ctor    (pointer to procedure named ‘__ctor’)

apx        (array of pointers to executable code)

r64        (64-bit double precision floating point constant)

a4,4r32    (4 x 4 array of 32-bit floats -- homogeneous matrix)

a,4r32     (array of arrays of 4 32-bit floats  --compare float (*)[4])

qu8        (16-bit offset to unsigned 8-bit integer -- in x86 segmented architecture)

aqx1432:i16    (array of offsets to 16-bit integers in the segment 0x1432)

aq'mySeg':p    (array of offsets to 32-bit pointers in the segment named 'mySeg’)

''         (structure of unknown type name. Reko generates a  type)

Clearly this needs to be improved; you should be able to enter any high-level types you want. Now that Reko has a full C parser, it should be updated to allow users to enter C types.

I do not know how to add a label or name to data. I do know how to change the name of a procedure, but it is very useful to change data names.

Agreed, this is not clear from the user interface. If you type a space followed by a label name, you're good: i32 my_integer declares an integer.

I'm going to add a new issue to Reko that collects these thoughts; the user interface for setting types is weak and can be improved.

When I examine the C source in the .h and .c files, there seem to be some macros for which I cannot find any definitions: e.g. CONVERT, SLICE.

During the decompilation process, Reko translates machine instructions into an architecture-neutral intermediate representation (IR). A later stage translates the IR into high-level language. The latter stage is supposed to use type information to translate CONVERT() applications to C-style (int32_t) casts. SLICE is a bit-extraction operation that can be modeled with shifts and and-masks. However, if Reko encounters an internal error during the latter stage, those primitives are not converted but left in the generated output. The reasoning is that it's better to have something than nothing, if something goes wrong. Ideally, Reko shouldn't be encountering internal errors, but all software has bugs. It helps us a lot if we get access to binaries causing these problems, so we can diagnose the issue(s) and fix them.

When I select File->Exit, I am not prompted to save the current project, even though I have made changes.

That's a clear bug, and should be fixed. Reko currently doesn't manage dirty stage not undo, so really it's a feature request.

I tried to make a metadata file named meta1.meta, but Reko tried to open as a binary file.

Currently, metadata files with an .inc extension will be loaded as a C header file. Extra Reko-specific annotations should be added to the metadata file as explained here: https://github.com/uxmal/reko/blob/master/doc/guide/usermetadata.md
You can edit the reko.config file so that the .meta extension is accepted, by adding the following XML element to the file:

      <Loader Extension="meta" Type="Reko.Core.Loading.CHeaderLoader,Reko.Core"
              Label="RekoCHeader" />

I'm a Python programmer these days; my C and C++ is very rusty now, and I'm not ready to dive into C# yet, but at some point I may have to. I might be more productive writing python scripts.

Reko does have an early-stage Python script interpreter. We use IronPython to execute said scripts. I'd love to have some real use cases to chew on, as it guides development work.

Again, my apologies for the late response. I will add a few open issues to cover the items above. Thanks for taking the time to write down your comments!