Process record does not support instruction 0xc5 at address...

Philippe Proulx
Mon Aug 15 00:00:00 GMT 2016

On Sun, Aug 14, 2016 at 7:08 PM, dwk <> wrote:
> Some context. I found that on an illegal instruction, or when jumping to
> an address where there was no mapped instruction, process record would
> fail in this way. It looks like 0xc5 is an undefined instruction in
> 64-bit mode (see so you appear
> to be running to the exact same issue.

Hmm, I disassembled `` and found those in said function:

  158a7:       c5 fd 7f 04 24          vmovdqa %ymm0,(%rsp)
  158ac:       c5 fd 7f 4c 24 20       vmovdqa %ymm1,0x20(%rsp)
  158b2:       c5 fd 7f 54 24 40       vmovdqa %ymm2,0x40(%rsp)
  158b8:       c5 fd 7f 5c 24 60       vmovdqa %ymm3,0x60(%rsp)
  158be:       c5 fd 7f a4 24 80 00    vmovdqa %ymm4,0x80(%rsp)

0x5c is the VEX prefix [1]. From [1]:

    The VEX prefix's initial-byte values, C4h and C5h, are the same as
    the opcodes of the LDS and LES instructions. These instructions are
    not supported in 64-bit mode.


    The AVX instruction set is the first instruction set extension to use
    the VEX coding scheme.

So this is not illegal, and I believe it's just that the GDB
instruction interpreter
does not support this set (yet) [2].

> My work-around was to write a
> script which would disable record, single-step to the next instruction,
> then re-enable record. However, I was intentionally adding undefined
> instructions and hoping for a SIGILL.
> The deeper issue here might be that some AVX instructions are not
> supported by process record. Thus, I suggest you disable the AVX versions
> of functions in libc, libm, and

This is a somewhat heavy solution but it could be done, possibly with -mno-avx.

> libm in particular makes heavy
> use of IFUNCs -- indirect symbols which are supposed to be called once to
> determine the real target function. Typically it looks at the supported
> features of your CPU and selects the appropriate function (AVX optimized,
> SSE optimized, SSE3 optimized, etc). It can't hurt to try disabling
> this. You can recompile libc (thus, or hack __init_cpu_features
> and thus __cpu_features at runtime (see e.g. strcmp).
> Oh, you can also try setting LD_BIND_NOW=1 so that symbols are all
> resolved immediately at load-time and _dl_runtime_resolve will never be
> called later, unless you dlopen of course.

This works. Thanks! Excellent workaround in the meantime, it did not occured
to me.



> On Sun, Aug 14, 2016 at 6:36 PM, Philippe Proulx
> <> wrote:
>> On Sun, Aug 14, 2016 at 5:42 PM, dwk <> wrote:
>>> I used to run into this all the time with SIGSEGV, SIGINT, instruction
>>> 0xcc, instruction 0xf4, etc. It seems to have been fixed when I upgraded
>>> gdb at one point. I am currently using gdb 7.7.1 on x86-64. Your mileage
>>> may vary.
>> I'm on 7.11.1 by the way.
>> Processor is Intel(R) Core(TM) i7-3520M with the following flags:
>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
>> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
>> constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
>> aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2
>> ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer
>> aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept
>> vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
>> Phil
>>> On Sun, Aug 14, 2016 at 5:30 PM, Philippe Proulx
>>> <> wrote:
>>>> Hello,
>>>> Is there any known solution or workaround for this problem when
>>>> using the GDB `record` command:
>>>>     Process record does not support instruction 0xc5 at address 0x7ffff7dee8a7.
>>>>     Process record: failed to record execution log.
>>>>     Program stopped.
>>>>     0x00007ffff7dee8a7 in _dl_runtime_resolve_avx () from
>>>> /lib64/
>>>> Thank you,
>>>> Philippe Proulx

More information about the Gdb mailing list