From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71094 invoked by alias); 13 Jun 2016 17:29:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 70940 invoked by uid 89); 13 Jun 2016 17:29:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sk:0xffff X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 13 Jun 2016 17:29:29 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 351B9C049E17; Mon, 13 Jun 2016 17:29:28 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5DHTR0R024771; Mon, 13 Jun 2016 13:29:27 -0400 Subject: Re: [PATCH 04/12] Delete reinsert breakpoints from forked child To: Yao Qi References: <1464859846-15619-1-git-send-email-yao.qi@linaro.org> <1464859846-15619-5-git-send-email-yao.qi@linaro.org> <86twgxt4hg.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 13 Jun 2016 17:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <86twgxt4hg.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00245.txt.bz2 On 06/13/2016 05:53 PM, Yao Qi wrote: > Pedro Alves writes: > >> Hmm, "\$pc - 20" doesn't look right for e.g., x86 with variable >> length instructions. I think that can well start disassembling >> in the middle of an instruction, and produce garbage. >> > > I thought 20 is big enough to include the previous instruction in. > The max instruction length of x86 is 16. If we disassemble in the > middle of an instruction, Yes, we do. > and garbage is printed, Yes, it does. Easily confirmed: (gdb) disassemble $pc,+10 Dump of assembler code from 0x7ffff78c55bb to 0x7ffff78c55c5: => 0x00007ffff78c55bb <__libc_fork+187>: cmp $0xfffffffffffff000,%rax 0x00007ffff78c55c1 <__libc_fork+193>: ja 0x7ffff78c5716 <__libc_fork+534> End of assembler dump. (gdb) disassemble $pc-1,+10 Dump of assembler code from 0x7ffff78c55ba to 0x7ffff78c55c4: 0x00007ffff78c55ba <__libc_fork+186>: add $0xf0003d48,%eax 0x00007ffff78c55bf <__libc_fork+191>: (bad) 0x00007ffff78c55c0 <__libc_fork+192>: decl (%rdi) 0x00007ffff78c55c2 <__libc_fork+194>: xchg %ecx,0x1(%rdi) End of assembler dump. (gdb) > it is a bug, and we should fix in disassembler. The problem is that with variable length instructions, there's no way to tell where an instruction starts by going backwards... All you can do is disassemble forward from some known instruction boundary. "disassemble" without a closed range uses the the function's address to know where to start. > I can't find another way to show the previous instruction. Now that the negative repeat count for 'x' patch [1] is in, you can just do "x/-i $pc". Maybe "disassemble" could learn to find boundaries similarly. But that x/-i trick only works if the code has line info available, which you won't for _exit, unless you have debug info for glibc installed. Maybe better is to just do "disassemble", with no args, which disassembles the whole function. Or do it like step-over-syscall.exp does. [1] https://sourceware.org/ml/gdb-patches/2016-06/msg00021.html >> I'm thinking that it might be good for these tests to also have >> a displaced-stepping on/off test axis. Or better still: >> >> out-of-line-step-over-bp / in-line-step-over-bp / plain-single-step >> > > What is difference between the second one and third one? As I mention in the quoted sentence below, the last one would single-step the instruction with no breakpoint installed. The second one would have a breakpoint at PC, which forces a step-over operation. With displaced step off, that'd be an in-line step over. Thus the second one stops all threads (and thus requires restarting them), while the third one doesn't. > I think > they've already covered by gdb.base/step-over-syscall.exp. In that case, shouldn't we be extending that test instead? > >> with the single-step variant doing a single-step over the >> syscall instruction, with no breakpoint at PC at all. > Thanks, Pedro Alves