bad instruction

[lcytxw]

After instrument, the binary exists lots of bad instruction, Is this normal?
401dfd: 27 (bad)
401dfe: 00 be cd 0c 45 00 add %bh,0x450ccd(%rsi)
401e04: e8 37 fb ff ff callq 401940 freopen@plt
401e09: e9 1f f5 39 00 jmpq 7a132d <main_dyninst+0xeef>
401e0e: c9 leaveq
401e0f: 10 00 adc %al,(%rax)
401e11: 00 e9 add %ch,%cl
401e13: 27 (bad)
401e14: f6 39 idivb (%rcx)
401e16: 00 27 add %ah,(%rdi)
401e18: 00 e8 add %ch,%al
401e1a: 42 fc rex.X cld
401e1c: ff (bad)
401e1d: ff (bad)
401e1e: e9 2f f7 39 00 jmpq 7a1552 <main_dyninst+0x1114>
401e23: 27 (bad)

[vanhauser-thc]

no that should absolutely not be the case and I have never seen that.

can you please attach the original binary and the instrumented one?

[vanhauser-thc]

Also please add the dyninst version you are using (last github commit)

[lcytxw]

dyninst/dyninst@9cb8bc5

bin.zip

[vanhauser-thc]

what you are refering to is not code, that is why it does not decode to something useful.

dyninst moves code around and makes space for its own magic. that is why the instrumented binary is much bigger and contains weird stuff :)

have you tried running it?

[lcytxw]

Yes, I tried. And this is one of the reason I looked at the disassembly code.
When I compared the result after executed this two binary, I found a different output:

id0.txt

afl-dyninst instrumented binary:
$ ./dwarf-dyninst queue/id:000000,orig:00050-libdwarf-negate-itself
#####################################################
Error getting shm

.debug_info
Segmentation fault
#####################################################

raw binary:
$dwarfdump queue/id:000000,orig:00050-libdwarf-negate-itself
#####################################################
.debug_info

./../libdwarf-code/install/bin/dwarfdump ERROR: dwarf_srcfiles: DW_DLE_MDE (10) mangled debugging entry:libelf detected error. Attempting to continue.

CU Name =
CU Producer = <no string provided?>
DIE OFF = 0x0000000b GOFF = 0x0000000b, Low PC = unknown , High PC = unknown

COMPILE_UNIT

:
< 0><0x0000000b> DW_TAG_compile_unit
DW_AT_producer <no string provided?>
DW_AT_language DW_LANG_C89
DW_AT_name <no string provided?>
DW_AT_comp_dir <no string provided?>
DW_AT_low_pc 0xe2e2e2e2e2e2e2e2
DW_AT_high_pc 0xe2c58b162c58b162 (-2106124323376287390)
DW_AT_stmt_list 0xe2e2e2e2
DW_AT_GNU_macros 0xe2e2e2e2

./../libdwarf-code/install/bin/dwarfdump ERROR: dwarf_child: DW_DLE_ABBREV_MISSING(394) Unable to find abbrev for DIE

CU Name = <no string provided?>
CU Producer = <no string provided?>
DIE OFF = 0x0000000b GOFF = 0x0000000b, Low PC = 0xe2e2e2e2e2e2e2e2, High PC = unknown
#####################################################

[vanhauser-thc]

OK this is something very different than what you first posted :)

when you gdb the instrumented library with that input file - at which address location does that occur? can you please show the exact core dump reason, registers, address and call stack?

[lcytxw]

I am looking for the problem.
By the way, there is a bug in the program.
344 if (string(moduleName).find(defaultModuleName) != string::npos) {
345 // defaultModule = (*moduleIter);
346 if (skipMainModule)
347 continue;
348 }

defaultModule may be changed by a binary which doesn't include "_init". for example:
warning: change defaultModule: dwarfdump
Instrumenting module: dwarfdump
Instrumenting module: checkutil.c
Instrumenting module: dwarf_dnames.c
Instrumenting module: dwarf_loc.c
warning: change defaultModule: dwarfdump.c
dwarfdump.c doesn't include func "_init", but it can change the defaultModule, which point to "_init".

so I do following change:
289 (*moduleIter)->getName(moduleName, 1024);
290 defaultModuleName = string(moduleName);
291 defaultModule = (*moduleIter);