From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26081 invoked by alias); 3 Jan 2011 10:27:48 -0000 Received: (qmail 26068 invoked by uid 22791); 3 Jan 2011 10:27:47 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_QE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.salomon.at (HELO sauxb.salomon.at) (193.186.16.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Jan 2011 10:27:41 +0000 Received: from servex01.wamas.com (servex01.salomon.at [172.28.2.2]) by sauxb.salomon.at (8.12.10/8.12.10) with ESMTP id p03AR5h9008865; Mon, 3 Jan 2011 11:27:06 +0100 (MET) Received: from [172.28.8.166] ([172.28.8.166]) by servex01.wamas.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 11:27:05 +0100 Message-ID: <4D21A474.2040909@salomon.at> Date: Mon, 03 Jan 2011 10:27:00 -0000 From: Markus Duft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101108 Lightning/1.0b3pre Thunderbird/3.1.6 MIME-Version: 1.0 To: qemu-devel@nongnu.org, gdb@sourceware.org Subject: Debugging a 64-bit kernel in qemu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2011-01/txt/msg00001.txt.bz2 Hi! I have been playing a little with this: I'm writing a kernel for both x86 and x86-64. While doing so, i'd like to debug the kernel using qemu (and it's gdb stub) and gdb. This worked very well until qemu-0.11.1 (gdb version does not seem to play any role...). From there on, debugging the 64 bit version no longer works. My sessions look like this with qemu-0.13.50 (and any version above 0.11.1, actually...): mduft@s01en22 /big/Privat/osdev/tachyon2 $ x86_64-pc-linux-gnu-gdb .build/x86_64/x86_64-tachyon GNU gdb (GDB) 7.2.50.20110103-cvs [snip] Reading symbols from /big/Privat/osdev/tachyon2/.build/x86_64/x86_64-tachyon...done. (gdb) target remote:1234 Remote debugging using :1234 0x0000000000000000 in ?? () (gdb) b boot Breakpoint 1 at 0xffffffff80119000: file /big/Privat/osdev/tachyon2/core/tachyon.boot/Entry.cc, line 25. (gdb) c Continuing. Remote 'g' packet reply is too long: 09ea1180ffffffff00950000000000000000000000000000000010000000000002b0ad2b009500000095000000000000d6101180ffffffffce101180ffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000901180ffffffff4600000018000000100000001000000010000000100000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 (gdb) quit actuallly, i _can_ debug the kernel, nut only until the long mode switch occurs. after this point: no luck... :[ now for the questions: 1) is this a problem with qemu or was qemu "fixed" and gdb has a problem? (that's why i CCd the gdb list ;)). 2) is there any plan to fix this issue? 3) is there some kind of workaround i can use (i'd be happy with an ugly/unsupported patch too, since i build all my stuff myself ;)). Thanks in advance! Regards, Markus