From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17096 invoked by alias); 17 Jul 2013 16:07:46 -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 17071 invoked by uid 89); 17 Jul 2013 16:07:45 -0000 X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO mail-la0-f43.google.com) (209.85.215.43) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 17 Jul 2013 16:07:44 +0000 Received: by mail-la0-f43.google.com with SMTP id gw10so1659378lab.16 for ; Wed, 17 Jul 2013 09:07:35 -0700 (PDT) X-Received: by 10.152.87.101 with SMTP id w5mr3041420laz.48.1374077255485; Wed, 17 Jul 2013 09:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.20.231 with HTTP; Wed, 17 Jul 2013 09:07:20 -0700 (PDT) In-Reply-To: <20130717120954.GA26158@dalaran.sceen.net> References: <51E5785D.1050904@codesourcery.com> <51E58223.5040505@codesourcery.com> <20130717120954.GA26158@dalaran.sceen.net> From: Yue Lu Date: Wed, 17 Jul 2013 16:07:00 -0000 Message-ID: Subject: Re: how to continue from a breakpoint in GNU/Hurd To: Richard Braun Cc: Luis Machado , gdb@sourceware.org, bug-hurd@gnu.org, Thomas Schwinge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-07/txt/msg00055.txt.bz2 Hi. On Wed, Jul 17, 2013 at 8:09 PM, Richard Braun wrote: > On Wed, Jul 17, 2013 at 02:11:58PM +0800, Yue Lu wrote: >> When I get the exception message, I set the EIP to the next instruction >> (for instance 0x12345678), after resume it, I call get_thread_state(), a= nd >> found the EIP is still 0x12345678. The inferior never running anymore. > > I don't think it has anything to do with the instruction cache. Use the > thread_info() call to determine what the suspend count is, it may have > been incremented implicitely. when I used thread_info() to check the suspend count, they are zero. But I met a strange thing. this is my code snippet: thread_basic_info_data_t _info; thread_basic_info_t info =3D &_info; mach_msg_type_number_t info_len =3D THREAD_BASIC_INFO_COUNT; error_t err =3D thread_info (thread->port, THREAD_BASIC_INFO, (int *) &info, &info_len); after this call, the info turn out to be a _NULL_ pointer. I think something maybe wrong, but the err is zero. In thread_takeover_sc_cmd() [gdb/gdb/gnu-nat.c] it has directly access info after thread_info call, so I think this pointer never become a NULL pointer, but in my code, it does. So I think something maybe wrong, or this is a bug in gdb code. -- Yue Lu (=E9=99=86=E5=B2=B3)