stderr causing problems.

[ianamason]

We are trying to lift a simple helloworld.c example on ubuntu 14.0 i386 where we print to
stderr rather than the implicit stdout.

bitcode_from_cfg/cfg_to_bc -i version0.cfg -driver=mcsema_main,main,2,return,C -o version0.bc
Already have driver for: main
Inserted function: sub_8000000
inserting global data section named data_0x800007d
error:
Line: 90
File: /home/cib/Repositories/mcsema/mc-sema/cfgToLLVM/x86Instrs_MOV.h
Could not find external: stderr

Is there something we can do to make progress here?

We are still trying to figure out where and why our lifted bytecode is SIGSEGV-ing.

[artemdinaburg]

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>

[ianamason]

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!

[ianamason]

And peeping into the bytecode reveals:

declare i32 @stderr()

which doesn't look right...

[artemdinaburg]

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

[farlies]

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?

[artemdinaburg]

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...

[ghost]

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

[artemdinaburg]

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.

[pgoodman]

@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.