From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SJIzAeZXGWB6LAAAWB0awg (envelope-from ) for ; Tue, 02 Feb 2021 08:47:18 -0500 Received: by simark.ca (Postfix, from userid 112) id 02DB81EF80; Tue, 2 Feb 2021 08:47:18 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A906C1E939 for ; Tue, 2 Feb 2021 08:47:15 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 65D2A398880D; Tue, 2 Feb 2021 13:47:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65D2A398880D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612273635; bh=jZvZDoJ+K/S2XJGkjCDvaX3jtbORBEtJvaSvpTj362M=; h=Subject:In-Reply-To:Date:References:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=BW4Vb0H/5lGCEe8kQvWylGO4tkl5NhRBe3uoLckQkfp85xH/NPPBCm7XTfdVSUujM x5P+HKKQVoZVKTFRsq6/RtWRGqvb1dlNFuIIQxa6gtTXyJmbm4wfdT9pBbUgRPkGTx BgeA+ZssTPIHT7hcb5v4kyXBlUrN1PPag2U814r8= Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by sourceware.org (Postfix) with ESMTPS id B3DFB3987C3B for ; Tue, 2 Feb 2021 13:47:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B3DFB3987C3B Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 6uoLlpethsjoS6w1OlT40X; Tue, 02 Feb 2021 13:47:10 +0000 Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-ch2-06v.sys.comcast.net with ESMTPSA id 6w1LlECOTRxAF6w1NlHfBN; Tue, 02 Feb 2021 13:47:10 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduledrgedtgdehiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedvtdevjeeuhefhiedvteffjeeuffehkefgudeutdevffefkeeijeelfeevuefhgeenucfkphepjeefrdeitddrvddvfedruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehpkhhonhhinhhgrdgrkhguvghsihhgnhdrtghomhdpihhnvghtpeejfedriedtrddvvdefrddutddupdhmrghilhhfrhhomhepphgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheplhgvohhnrdhhvgesmhhsnhdrtghomhdprhgtphhtthhopehguggssehsohhurhgtvgifrghrvgdrohhrgh X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl. In-Reply-To: Date: Tue, 2 Feb 2021 08:47:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: He Leon X-Mailer: Apple Mail (2.3445.104.17) X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul Koning via Gdb Reply-To: Paul Koning Cc: "gdb@sourceware.org" Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" > On Feb 2, 2021, at 7:13 AM, He Leon via Gdb = wrote: >=20 > Hi all, >=20 > I meet an issue while debugging APP by gdb. >=20 > I have a very simple APP and a very simple Kernel Mode Driver. APP = accesses Kernel Mode Driver via IOCTL. >=20 > When I debug APP in User Mode by gdb, I found if APP enters and stays = inside IOCTL, the APP cannot be interrupted to gdb console by control+C. >=20 > The issue is quite easy to be reproduced. I have reproduced it over = different versions of kernel or gdb. >=20 > Is there such limitation for: gdb doesn't work if APP enters and stays = in kernel mode? Of course, and that is true for every debugger. Debugger interrupt = works by delivering a signal to the process. If the process is in a = state where a signal can't be delivered to it (such as in a driver = operation which you have coded not to be interruptable) then the signal = remains pending until the blocking operation finishes. You probably need to do some kernel mode debugging to fix your driver = first. paul