From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v5 00/17] xenctx: Many changes. Date: Fri, 21 Mar 2014 13:37:03 -0400 Message-ID: <532C78BF.1000801@terremark.com> References: <1395342425-16260-1-git-send-email-dslutz@verizon.com> <1395414878.19839.139.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1395414878.19839.139.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Stefano Stabellini , George Dunlap , Ian Jackson , Don Slutz , xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 03/21/14 11:14, Ian Campbell wrote: > On Thu, 2014-03-20 at 15:06 -0400, Don Slutz wrote: >> Add more functionality to xenctx. > So, I've been through this and it mostly seems independently useful, but > the overriding thought I've been having is: aren't you piecemeal > reinventing the debugger (like gdbsx)? Sort of. If this were a new command, I would think that "reinventing the debugger" would be more important. There are several issues with using gdbsx to get a quick look at a domU: 1) you need to start gdbsx & gdb 2) gdb does not simply take a System.map file, nor is vmlinuz a big help. There is most likely a way to get gdb to use a System.map but I do not currently remember it. 3) Getting a call trace in gdb is hard without debugging symbols. And last I knew there was no native command to format it like xenctx: Call Trace: [] default_idle+0x29 <-- [] cpu_idle+0x95 [] start_kernel+0x220 [] x86_64_start_kernel+0x22f 4) You need to remember if this domU is in 32 or 64 bit mode (looks like saying 64, for a 32 may be ok). 5) Older gdb's do not display the registers that xenctx does. The main new features would be -d and -m. The rest are enhancements or fixes. Hope this helps. -Don Slutz > Ian. >