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

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Wed, Jan 03, 2007 at 09:21:08PM +0000, Keir Fraser 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.

It was more of an answer to your question as to why there would be any
point in shipping a standard symtab rather than the Linux thing.
Essentially it makes things much easier for us as our debug info relies
on a standard symtab.

> 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.

I had in mind something very much like this, we'd just append the
symtab,strtab, and our debug info on to the image and set something to
point to the location. This was mostly a workaround of the difficulties
with building those sections straight into the file in the normal ELF
manner, though.

I think the question might more be: what do we gain from being
'unusual'? A significantly smaller string size for the symbol names
might be a reasonable answer, I don't really know how much of a gain
that stuff is. An entertaining logic puzzle in the makefiles, perhaps
not ;)

Of course it would still be a /little/ unusual because you'd want the
symtab etc. as allocated PROGBITS.

regards,
john

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