From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16152 invoked by alias); 6 Jan 2009 23:59:47 -0000 Received: (qmail 16142 invoked by uid 22791); 6 Jan 2009 23:59:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Jan 2009 23:59:42 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id n06NxeJQ004660 for ; Tue, 6 Jan 2009 15:59:40 -0800 Received: from rv-out-0506.google.com (rvbk40.prod.google.com [10.140.87.40]) by wpaz5.hot.corp.google.com with ESMTP id n06Nxb8m014483 for ; Tue, 6 Jan 2009 15:59:37 -0800 Received: by rv-out-0506.google.com with SMTP id k40so7887224rvb.29 for ; Tue, 06 Jan 2009 15:59:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.37.8 with SMTP id p8mr11174037rvj.227.1231286376877; Tue, 06 Jan 2009 15:59:36 -0800 (PST) In-Reply-To: <4960BAC8.7020801@web.de> References: <4960BAC8.7020801@web.de> Date: Tue, 06 Jan 2009 23:59:00 -0000 Message-ID: Subject: Re: Towards better x86 system debugging support From: Doug Evans To: Jan Kiszka Cc: gdb@sourceware.org, Daniel Jacobowitz 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: 2009-01/txt/msg00028.txt.bz2 On Sun, Jan 4, 2009 at 5:34 AM, Jan Kiszka wrote: > Hi, > > as many of you may know, there is a gdb server in QEMU that allows to > debug kernels, boot loaders and other low-level stuff without real > target hardware. I'm e.g. using it heavily for analyzing Linux kernel > issues on x86 targets (thanks to KVM, you can even debug weird SMP races > in NMI-using kernel debuggers...). > > 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: > > o Current code bit width (16, 32 or 64) is unknown to the debugger, > so correct disassembling is not automatically possible > o Real mode cannot be detected, which would include setting 16 bit > disassembly mode and calculating segment bases appropriately > 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) > 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) > > 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: > > 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 know of one linux program that uses modify_ldt() and changes all segment registers, so I would add cs_base,ds_base,es_base,ss_base. Some folks would presumably find *_limit, *_flags useful too.