From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54536 invoked by alias); 15 Aug 2016 00:00:37 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 54496 invoked by uid 89); 15 Aug 2016 00:00:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:www.google.com, wwwgooglecom, www.google.com, LES X-HELO: mail-qk0-f174.google.com Received: from mail-qk0-f174.google.com (HELO mail-qk0-f174.google.com) (209.85.220.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Aug 2016 00:00:24 +0000 Received: by mail-qk0-f174.google.com with SMTP id v123so31438588qkh.2 for ; Sun, 14 Aug 2016 17:00:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=weA+FM+mMqIDf19akxpUvFULGTESc1DVSsx+yzBWM90=; b=iPK1PDu+TUpTatZ42HquqWR2MDRAr7zO1Z5pgf+5JYyCuCmddVnCosEdigXvw1SLFE neUwwWbhljYVRmx9jBbjCz0oXgfhKjK+D6eTdAC9w4K1a9XLkKjF7HfhQWdbeuznZUcF TSs3JYPT7SMuOMomSRqch101U2oW9926JCQG9TtqiDhekiT7kP1tPOU0WEOCvt8jb+yl RMVU26bEpzIY5X2JedLUjJwlwjc4mWdMC5bOl/lMm3/Mfl83Ck8Bbqy7QMM8cMmdKNot LIMA4Hq0hU+8jSmCzlJyh9k22IXS6HJFSW0EHYo4MkKk+ioh6jfbNNszkC1K/6gu8obB Ivow== X-Gm-Message-State: AEkoouvZJ+2iYM5YQLy5DiMdgE0M+hKpMRhdIoluC+RSEbQhcSFfGEo6xULTGpZPsIxdaKiONaHsDwnL+llY2w== X-Received: by 10.55.10.148 with SMTP id 142mr28826948qkk.187.1471219223283; Sun, 14 Aug 2016 17:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.148 with HTTP; Sun, 14 Aug 2016 16:59:52 -0700 (PDT) In-Reply-To: References: From: Philippe Proulx Date: Mon, 15 Aug 2016 00:00:00 -0000 Message-ID: Subject: Re: Process record does not support instruction 0xc5 at address... To: dwk Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-08/txt/msg00029.txt.bz2 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 http://ref.x86asm.net/coder64.html#xC5) so you appear > to be running to the exact same issue. Hmm, I disassembled `ld-linux-x86-64.so.2` 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. and: 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 ld.so. 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 ld.so), 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. [1] https://en.wikipedia.org/wiki/VEX_prefix [2] https://www.google.com/url?q=https%3A%2F%2Fsourceware.org%2Fgit%2Fgitweb.cgi%3Fp%3Dbinutils-gdb.git%3Ba%3Dblob%3Bf%3Dgdb%2Fi386-tdep.c%3Bh%3D92987af8101ccde68c892699b9a8dee30e9dc9c9%3Bhb%3DHEAD%23l5906&sa=D&sntz=1&usg=AFQjCNG4XN_OosfwyfBmUa9qISDBWVVpbQ Phil > > 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/ld-linux-x86-64.so.2 >>>> >>>> Thank you, >>>> >>>> Philippe Proulx