From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12616 invoked by alias); 16 Jul 2013 17:26:07 -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 12590 invoked by uid 89); 16 Jul 2013 17:26:07 -0000 X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 16 Jul 2013 17:26:06 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Uz90h-0001JH-3o from Luis_Gustavo@mentor.com ; Tue, 16 Jul 2013 10:25:59 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 10:25:59 -0700 Received: from [172.30.1.104] ([172.30.1.104]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jul 2013 10:25:58 -0700 Message-ID: <51E58223.5040505@codesourcery.com> Date: Tue, 16 Jul 2013 17:26:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yue Lu CC: Luis Machado , gdb@sourceware.org, bug-hurd@gnu.org, Thomas Schwinge Subject: Re: how to continue from a breakpoint in GNU/Hurd References: <51E5785D.1050904@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00047.txt.bz2 Hi, On 07/16/2013 02:04 PM, Yue Lu wrote: > Hi, > > thanks for you reply. > > On Wed, Jul 17, 2013 at 12:44 AM, Luis Machado >> Some general thoughts... >> >> Can you make sure the breakpoint has been lifted from the instruction it >> replaced? If the breakpoint has been lifted and it is still being hit, then >> it sounds like there is some kind of instruction cache problem going on, >> where we first need to flush the icache before resuming execution. >> >> If the icache is the problem, then it sounds like something the kernel >> itself needs to address. >> >> Luis > > I don't know how to flush the icache off-hand, so I used anther way to > bypass this issue. I set the eip to the next instruction's address to > bypass the breakpoint ins. But problem seems doesn't go away. I don't think the cache invalidation is something the debugger should do. Sounds like something the kernel would do. When you set the EIP to some other instruction (not the breakpoint one), what do you see when you instruction-step? What does the EIP show after that? Luis