source code is not generated

[dark1st]

Hello,

Thank you for your project.

Looks like I found some kind of issue:

I'm trying to build dwarf info together with sources.
Ida 6.8 + ARM Decompiler 2.2.0

as the output I have dbg file with some data and 0 size for the source file.
In the dialog box I checked option Use Decompiler

---

Best regards, Alexey

[ALSchwalm]

Are you running on Windows? In general you will probably need the current version of IDA (6.95). If you are on linux or osx you can try building from source, but on Windows this isn't easy. I have not yet documented the build process because it involves a bunch of mingw tricks.

[dark1st]

Yes, I'm using plugin from the bin folder on Windows.
Unfortunately I don't have 6.95

could you compile windows plugins using 6.8 sdk?
if it could help.

Thank you in advance.

[ALSchwalm]

To my knowledge, I can't get an older version of the SDK from IDA, and I don't have a copy of 6.8. However, this weekend I should be able to get the instructions for building on Windows added, so you can build with 6.8 and see if that works.

[dark1st]

try this one https://yadi.sk/d/zTTZeJB13KNqUb

[ALSchwalm]

Here's a version linked against that sdk: https://gist.github.com/ALSchwalm/fd6eb3d6dd6b74bde2dba522bd5d1dc8

Also, if that doesn't work, can you just run 'idaapi.decompile(here())' in the python prompt in some function? I don't have the ARM decompiler at the moment, so I don't have a great way to test this.

[dark1st]

plugin doesn't build C source file, it just creates it.

idaapi.decompile(here()) - does work and produces an output to the console.

could you add more debug printf to check what is going on?

could you have a problem with de compilation plugin presence detection?

[ALSchwalm]

The C file shouldn't be created at all if the decompiler isn't detected, but I agree that more debug stuff would be useful. I'll add a 'verbose' option to the plugin. I won't be able to do windows builds until next weekend though.

[ALSchwalm]

Updated that gist link with a verbose option that will create a log file, and a few bug fixes.

[dark1st]

this is what I have in the console right after load and execution of manual decompilation command

IDAPython Hex-Rays bindings initialized.
dwarfexport: No decompiler found

Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
IDAPython v1.7.0 final (serial 0) (c) The IDAPython Team idapython@googlegroups.com

Python>idaapi.decompile(here())
void Reset_Handler()
{
uint32_t *v0; // r1@1
uint32_t *i; // r2@1
uint32_t v2; // t1@3
debug_console_state_t *j; // r1@4

__disable_irq();
vE000ED08 = 0;
SystemInit();
v0 = (uint32_t *)48292;
for ( i = &s_slowIrcFreq; (signed int)i < (signed int)&s_debugConsole; ++i )
{
v2 = *v0;
++v0;
*i = v2;
}
for ( j = &s_debugConsole; (signed int)j < 536808960; j = (debug_console_state_t *)((char *)j + 4) )
*(_DWORD *)&j->type = 0;
__enable_irq();
main();
}

So I have a decompiler, but a plugin can't detect it

Here is an attempt to do dwarf export
dwarfexport: No decompiler found
Verbose mode enabled. Logging to dwarfexport.log

[ALSchwalm]

I tested this out with a 6.95 arm decompiler and it works, so I'm guessing this a difference in load order of plugins from 6.8 to 6.95. Maybe try renaming dwarfexport.plw to hexrays_dwarfexport.plw?

[dark1st]

0_dwarfexport.pwl
hexrays_dwarfexport.plw
z_dwarfexport.plw

doesn't work, the same error
IDAPython Hex-Rays bindings initialized.
dwarfexport: No decompiler found

according to the plugins.cfg
; if present, load Hex-Rays decompiler before all other plugins

    Hex-Rays_Decompiler         hexrays     0       0  SILENT
    Hex-Rays_Decompiler         hexarm      0       0  SILENT
    Hex-Rays_Decompiler         hexx64      0       0  SILENT

    ; Other plugins

hexrays stuff is loaded 1st

can you disable hexrays plugins check and take into account checkbox value only?

[teeeer]

Hello!

I've got same problem on ida 6.8:
dwarfexport: No decompiler found

I found how to fix it.
the problem: wrong HEXRAYS_API_MAGIC2 from hexrays.hpp.
You need to change it. For example: from 0xBE3EBABE (in this build) to 0xBE3CBABE

[teeeer]

In my opinion it is more correct to get the line address in func add_decompiler_func_info like this:
if (item.citype == VDI_EXPR)
{
const cinsn_t * itemInstruction = item.i;
boundaries_iterator_t it = boundaries_find(&bounds, itemInstruction);
if (it != boundaries_end(&bounds))
{
areaset_t lineArea = boundaries_second(it);
lineAddr = lineArea.getarea(0).startEA;
}
}