stderr causing problems. about mcsema HOT 9 CLOSED

Its looking for stderr as an external symbol and can't find it. Create a definitions (e.g. std_defs.txt) with:
DATA: stderr 1

Use the -func-map argument with IDA/bin_descend.

The format for data entries is:
DATA: <symbol> <size of symbol in bytes>

from mcsema.

We tried both:

DATA: stderr 4

and

DATA: stderr 1

But either way we end up with:

Already have driver for: main
Inserted function: sub_8000000
inserting global data section named data_0x800007d
Adding entry point: mcsema_main
invalid linkage type for global declaration
i32* @stderr
Could not verify module!

or

Already have driver for: main
Inserted function: sub_8000000
inserting global data section named data_0x800007d
Adding entry point: mcsema_main
invalid linkage type for global declaration
i8* @stderr
Could not verify module!

from mcsema.

And peeping into the bytecode reveals:

declare i32 @stderr()

which doesn't look right...

from mcsema.

Hmm yes that does look bad. I'll investigate and see why its not processing it properly.

from mcsema.

I tripped across the same issue with stdout, and tried DATA: with similar lack of effect. (32-bit ELF) Presumably any .dynbss refs will have this glitch. My peeping (in gdb) suggests it is just being handled as uninitialized storage. Is there a workaround?

from mcsema.

Thanks for that tip. Let me look into this and see what special about .dynbss. I'm hoping its simply a case of handling R_386_COPY relocations...

from mcsema.

Hello, I am also having the same issue. Did you guys figure out the solution? If so, please share it with me so that I can make some progress with my work.

Thanks

from mcsema.

I'd have to see if this is fixed in the very latest merge to master. I remember attempting to fix it, but not sure if the fix made it.

The core issue is that stderr is the first item in the start of a new section. IDA sees references to stderr as references to the .data section, and not to the external symbol named stderr. The reference does not get correctly detected during CFG recovery, and therefore is not correctly emitted in the translated binary.

from mcsema.

@ianamason or @mcuramen Are you having this issue in the llvm38 branch? Make sure to read the README to see the new build and running process.

from mcsema.