From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2863 invoked by alias); 31 Oct 2011 17:16:36 -0000 Received: (qmail 2832 invoked by uid 22791); 31 Oct 2011 17:16:35 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,TW_VP X-Spam-Check-By: sourceware.org Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Oct 2011 17:16:20 +0000 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id p9VHGCog008945; Mon, 31 Oct 2011 18:16:13 +0100 Received: from mchn199C.mchp.siemens.de ([139.25.109.49]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id p9VHGCah029027; Mon, 31 Oct 2011 18:16:12 +0100 Message-ID: <4EAED7DC.5030805@siemens.com> Date: Mon, 31 Oct 2011 17:18: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: Vimal CC: Tom Tromey , gdb@sourceware.org Subject: Re: Multiple breakpoint issue when debugging loadable kernel module References: <4EA89365.2010807@web.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2011-10/txt/msg00238.txt.bz2 On 2011-10-28 05:39, Vimal wrote: > Some more info. This looks interesting. > > 1. find_pc_sect_symtab has changed quite a bit between the faulty > commit noted above (sha 2cdbbe44) and its parent (2cdbbe44^)! > > 2. Since the module is loaded into the kernel address space, > find_pc_sect_symtab seems to think the vmlinux module's symbol table > has symbol information for the function I am breaking into. Some > prints from find_pc_sect_symtab for a LKM function seems to return > vmlinux's symtab! :( > > find_pc_sect_symtab(pc=0xffffffffa00d5bb8,sec=0x20fb988) > objfile=0x11cbc40, name=/usr/src/linux-cfs-bw/vmlinux > Returning 0x2690cc0 (objfile=0x11cbc40) # Which is vmlinux > > So, I checked the BLOCK_START and BLOCK_END for the vmlinux image. I got this: > start=0xffffffff8102eb10 > end=0xffffffffff60017f > > and pc=0xffffffffa00d5bb8 was very well within start and end, so it > chose vmlinux. :( > > So, I tired this (without loading vmlinux's symbols) > > (gdb) target remote localhost:1234 > (gdb) add-symbol-file (for module) > (gdb) info scope module_function > (got info) > (gdb) break module_function > (correct break) > (gdb) info scope module_function > (got correct info! it works!) > > All locals/args info is retained. > > So, to combat this, I presently do this (load vmlinux _after_ loading > module symbols) > > gdb (without vmlinux) > (gdb) target remote ... > (gdb) add-symbol-file (for module) > (gdb) file vmlinux > (gdb) break vport_receive > Breakpoint 1, vport_receive (vport=0xffff880115fa7200, > skb=0xffff880117580900) at > /home/nikhilh/openvswitch/datapath/linux/vport.c:643 > 643 if (vport->ops->flags & VPORT_F_GEN_STATS) { > > With full information. > > I am also able to break into Linux functions, like sys_write for e.g. > > Jan: can you try this and tell us if it works? Yes, that works (around the bug). But it does not help me as it's unhandy (gdb assumes 32-bit by default, my kernels are 64 usually) and automatic module loading depends on the kernel symbols already being present. Tom, do you still like to have a description of the full reproduction scenario or are you debugging via Vimal? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux