From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17780 invoked by alias); 13 Jan 2015 14:22:33 -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 17674 invoked by uid 89); 13 Jan 2015 14:22:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: thoth.sbs.de Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 13 Jan 2015 14:22:29 +0000 Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.14.3/8.14.3) with ESMTP id t0DEMKGi031366; Tue, 13 Jan 2015 15:22:21 +0100 Received: from md1f2u6c.ww002.siemens.net (md1f2u6c.mch.sbs.de [139.25.40.156] (may be forged)) by mail3.siemens.de (8.14.3/8.14.3) with ESMTP id t0DEMK30010584; Tue, 13 Jan 2015 15:22:20 +0100 Message-ID: <54B52A1B.1090409@siemens.com> Date: Tue, 13 Jan 2015 14:22:00 -0000 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: gdb@sourceware.org, Pedro Alves Subject: python-injected silent breakpoints broken since 1a853c52 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg00018.txt.bz2 Hi, I've stumbled over a regression of gdb since commit 1a853c52 (make "permanent breakpoints" per location and disableable). My gdb python scripts [1] that load Linux kernel module symbols as the target loads the modules now fail. The involved command is lx-symbols [2]. It installs a silent breakpoint on a kernel function that is called when a module is loaded. Before 1a853c52, the python callback was normally invoked and the target continued to run. Since af48d08f (1a853c52 is not testable), the int3 instruction (I'm testing with x86) is left in the target, and garbage instructions are executed, causing a kernel oops. The breakpoint is apparently not properly skipped (remove, single-step, re-insert) when resuming the target on return from LoadModuleBreakpoint.stop(). I can provide more details on how to set up a reproduction case but I would only gather them when desired as that is not straightforward. Jan [1] https://lkml.org/lkml/2014/11/20/531 [2] http://git.kiszka.org/?p=linux.git;a=blob;f=scripts/gdb/linux/symbols.py;h=bf05e451c58666add299061046bf1ceb9e82f4ef;hb=d92098e7cf60d31ccd025e56d20c23917ccd0819 -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux