From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7575 invoked by alias); 5 Jan 2009 20:20:55 -0000 Received: (qmail 7559 invoked by uid 22791); 5 Jan 2009 20:20:54 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jan 2009 20:20:49 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n05KKhmx026298; Mon, 5 Jan 2009 21:20:43 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n05KKg3d014109; Mon, 5 Jan 2009 21:20:42 +0100 (CET) Date: Mon, 05 Jan 2009 20:20:00 -0000 Message-Id: <200901052020.n05KKg3d014109@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: jan.kiszka@web.de CC: gdb@sourceware.org, drow@false.org In-reply-to: <4960BAC8.7020801@web.de> (message from Jan Kiszka on Sun, 04 Jan 2009 14:34:00 +0100) Subject: Re: Towards better x86 system debugging support References: <4960BAC8.7020801@web.de> 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: 2009-01/txt/msg00015.txt.bz2 > Date: Sun, 04 Jan 2009 14:34:00 +0100 > From: Jan Kiszka > > Hi, > > Unfortunately, the x86 support is incomplete in so far that neither the > gdb remote protocol nor the gdb backend are aware of most special > registers x86 system-level software uses. This comes with several drawbacks: Yes there are some limitations. What's there is mostly adequeate for debugging traditional C kernel code. And I for myself have always considered implementing the bits needed for more low-level code an effort too big to be worth it (how much 16-bit code is there in the Linux kernel?). But if you think otherwise, feel free to contribute the appropriate code. > o Current code bit width (16, 32 or 64) is unknown to the debugger, > so correct disassembling is not automatically possible It's tricky to figure this out when running on real hardware, but I suppose it would be trivial for an emulator like QEMU to tell GDB what mode it's in. The idea has always been that GDB would become multi-arch and that every frame would have an architecture associated with it. Perhaps that's the way to go. > o Real mode cannot be detected, which would include setting 16 bit > disassembly mode and calculating segment bases appropriately Sorry, what are you trying to say here? > o Manually setting the architecture (set arch i8086/i386/i386:x86-64) > influences the register set layout of the remote protocol, preventing > straightforward switches from 16-bit bootloader/BIOS code to 64-bit > kernel code (to give just one example) Even worse, it changes the layout of GDB's internal register cache. And I'm not even sure it is feasable to unify the i386 and amd64 layouts in a meaningful way. > o Only flat memory models are supported and debugging becomes very > hairy when some segment uses a non-zero base address - note that this > also prevents support for TLS variable lookup (which is GS or > FS-based) This problem is not unique to the i386/amd64 targets. There are other architectures that have more than one address space. Unfortunately, I believe nobody has really implemented a satisfactory solution to implement them properly in GDB. Not that the TLS problem has been solved already (in a satisfactory way I think). I'm not sure making GDB aware of %gs and %fs would really help here. Systems use those registers in different ways, and they don't really help when you want to look at variables in a different thread than the one you're running isn't it? > As a first step toward enhanced x86 support, I think there is a need for > an extended register set in the remote protocol. The following registers > should be added: Sorry, but I think you're starting at the wrong end here. You should probably first add support for additional registers to GDB's internal register cache. It doen't make sense to worry about the remote protocol until that's done. > o GDTR, LDTR, IDTR, TR (visible part, ie. selector value) > o CR0..4 > o DR0..7 > o selected MSRs, at least > - IA32_EFER (64-bit mode detection) > - IA32_FS_Base (TLS) > - IA32_GS_Base (TLS) > - IA32_KernelGSbase (TLS) > o Shadow states of segment registers, GDTR, LDTR, IDTR and TR > (relevant for virtual targets where the VM often has access to these > hidden states, helpful when debugging targets that modify in-use > descriptor table entries) > > If anyone thinks that there should be more registers or MSRs included, > please extend this list! I don't think it is a good idea to start adding MSRs to GDB's internal register cache. There are zillions of them. It is probably a better idea to implement them as a seperate address space. One thing that's probably a good idea before starting hacking on all this is to fully decouple the layout of the internal register cache from the remote protocol such that when you change things there, you don't have to worry about breaking existing remote stubs.