From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6168 invoked by alias); 23 Jul 2008 09:18:44 -0000 Received: (qmail 6150 invoked by uid 22791); 23 Jul 2008 09:18:43 -0000 X-Spam-Check-By: sourceware.org Received: from an-out-0708.google.com (HELO an-out-0708.google.com) (209.85.132.241) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Jul 2008 09:18:25 +0000 Received: by an-out-0708.google.com with SMTP id c37so1073644anc.42 for ; Wed, 23 Jul 2008 02:18:23 -0700 (PDT) Received: by 10.100.95.19 with SMTP id s19mr3009828anb.65.1216804703256; Wed, 23 Jul 2008 02:18:23 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Wed, 23 Jul 2008 02:18:23 -0700 (PDT) Message-ID: <5d649bdb0807230218r95387a0xce444b3d832e6675@mail.gmail.com> Date: Thu, 24 Jul 2008 00:07:00 -0000 From: "Neo Jia" To: "Michael Snyder" Subject: Re: Is add-symbol-files broken on 64bit? (Need help!!!) Cc: gdb@gnu.org, gdb@sourceware.org, zhanrongkai@hotmail.com In-Reply-To: <5d649bdb0807201853p5b5e4d16q2d7bcae08e24930e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d649bdb0807180100u58ec702g2a79a43173736dc8@mail.gmail.com> <5d649bdb0807180102l6d453ed0rb2ba277812095e12@mail.gmail.com> <1216597050.3549.442.camel@localhost.localdomain> <5d649bdb0807201853p5b5e4d16q2d7bcae08e24930e@mail.gmail.com> X-IsSubscribed: yes 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: 2008-07/txt/msg00248.txt.bz2 This is the wired output from gdb after doing "info files". (gdb) info files Symbols from "/home/cjia/scratch/workareas/linux_kernels/linux-2.6/vmlinux". Remote serial target in gdb-specific protocol: Debugging a target over a serial line. While running this, GDB does not access memory from... Local exec file: `/home/cjia/scratch/workareas/linux_kernels/linux-2.6/vmlinux', file type elf64-x86-64. Entry point: 0x1000000 0xffffffff81000000 - 0xffffffff8128b4a3 is .text 0xffffffff8128b4b0 - 0xffffffff8128f260 is __ex_table 0xffffffff8128f260 - 0xffffffff8128f284 is .notes 0xffffffff8128f288 - 0xffffffff81296278 is __bug_table 0xffffffff81297000 - 0xffffffff8138c4f1 is .rodata 0xffffffff8138c500 - 0xffffffff8138d6e0 is .pci_fixup 0xffffffff8138d6e0 - 0xffffffff81397d50 is __ksymtab 0xffffffff81397d50 - 0xffffffff8139b5a0 is __ksymtab_gpl 0xffffffff8139b5a0 - 0xffffffff813afa9c is __ksymtab_strings 0xffffffff813afaa0 - 0xffffffff813b1000 is __param 0xffffffff813b1000 - 0xffffffff813ea1a8 is .data 0xffffffff813eb000 - 0xffffffff81439980 is .data.cacheline_aligned 0xffffffff81439980 - 0xffffffff8144b588 is .data.read_mostly 0xffffffffff600000 - 0xffffffffff6000ec is .vsyscall_0 0xffffffffff600100 - 0xffffffffff600131 is .vsyscall_fn 0xffffffffff600180 - 0xffffffffff6001d0 is .vsyscall_gtod_data 0xffffffffff600400 - 0xffffffffff60043c is .vsyscall_1 0xffffffffff600800 - 0xffffffffff600860 is .vsyscall_2 0xffffffffff600860 - 0xffffffffff600864 is .vgetcpu_mode 0xffffffffff600880 - 0xffffffffff600888 is .jiffies 0xffffffffff600c00 - 0xffffffffff600c0d is .vsyscall_3 0xffffffff8144e000 - 0xffffffff81450000 is .data.init_task 0xffffffff81450000 - 0xffffffff81451000 is .data.page_aligned 0xffffffff81451000 - 0xffffffff81457f08 is .smp_locks 0xffffffff81458000 - 0xffffffff8147f91b is .init.text 0xffffffff8147f920 - 0xffffffff814a12c0 is .init.data 0xffffffff814a12c0 - 0xffffffff814a2160 is .init.setup 0xffffffff814a2160 - 0xffffffff814a29c0 is .initcall.init 0xffffffff814a29c0 - 0xffffffff814a29d0 is .con_initcall.init 0xffffffff814a29d0 - 0xffffffff814a29e0 is .security_initcall.init ---Type to continue, or q to quit---q Quit Any idea about this? Thanks, Neo On Sun, Jul 20, 2008 at 6:53 PM, Neo Jia wrote: > The problem is that I can use the same way to debug 32bit env. Also, I > can see the debugging symbol and line numbers from the ko file. > > Thanks, > Neo > > On Sun, Jul 20, 2008 at 4:37 PM, Michael Snyder wrote: >> I have a vague recollection to the effect that kernel modules >> can be debugged in somewhat the same manner as shared libraries, >> but a quick google search didn't turn up anything very useful. >> >> Never done it myself, don't know anything more specific than that. >> >> On Fri, 2008-07-18 at 01:02 -0700, Neo Jia wrote: >>> Sorry, re-send with plain-text. >>> >>> Thanks, >>> Neo >>> >>> On Fri, Jul 18, 2008 at 1:00 AM, Neo Jia wrote: >>> > >>> > hi, >>> > >>> > I am using the gdb to debug Linux kernel module on x86-64 bit with a patched kernel (kgdb). Everything works fine for the kernel itself, I can break on any functions, and see the sources. But, I can't break on the symbols in the kernel module after it is loaded. I used the "add-symbol-files" to add the sections for that loadable module. >>> > >>> > The same setup works fine for 32bit and I even can see the symbols/sources by running gdb directly against the 64bit .ko file. >>> > >>> > Any suggestions? I am struggling with this question for a long time. >>> > >>> > Thanks, >>> > Neo >>> > >>> > -- >>> > I would remember that if researchers were not ambitious >>> > probably today we haven't the technology we are using! >>> >>> >>> >>> -- >>> I would remember that if researchers were not ambitious >>> probably today we haven't the technology we are using! >> >> > > > > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!