WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] mkelf32: Correct sh_link

To: John Levon <levon@xxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] mkelf32: Correct sh_link
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 03 Jan 2007 21:21:08 +0000
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 03 Jan 2007 13:20:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070103201116.GC1115@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccvfRVpU+eDkptwEduotgANk04WTA==
Thread-topic: [Xen-devel] [PATCH] mkelf32: Correct sh_link
User-agent: Microsoft-Entourage/11.3.2.061213
On 3/1/07 8:11 pm, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:

>> That would potentially be nice, but I don't know of any tools that would
>> allow us to symbolically debug a dump without having a separate source of
>> symbol information (like xen-syms).
> 
> This is exactly what is available on Solaris both for userspace core
> dumps and kernel crash dumps. We'd like to be able to extend this to
> Xen. As far as I know, there's nothing preventing, say, Red Hat's
> 'crash' doing the same.

Well, extracting symbols from the existing Xen format isn't hard. We could
add that, but really it's not as good as source-level debugging, being able
look at local variables up the call stack, etc. I don't think it is
expecting much to require xen-syms to be kept around for xen images that are
still being tested. Another trick might be to allow production of a xen
image with the full xen-syms image appended -- then a crash dump would have
all the info required to do full source-level debugging (except the source
tree, but you do get a changeset number from the core dump which will
suffice if you use revision control). That would be easy actually -- just
get mkelf32 to append the xen-syms file and set a couple of values at a
known offset in the main xen image, easily picked up by crashdump tools and
by Xen itself.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel