Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 07/01/2010 10:13 PM, Mukesh Rathor wrote:
> Thanks for CC Konrad, I'm gazillions postings behind in catching up
> xen-devel.
>
> Bruce, you don't need to use the ext repo anymore as gdbsx is now
> merged mainline. I should update the blog post.
>
> To build a debug enabled xen image: make gdbsx=y  is all you need
> to do. After booting with gdbsx enabled xen, you can run gdbsx in
> dom0. See tools/debugger/gdbsx/README. 
>   

I noticed when I tried gdbsx today that it doesn't seem to deal with
multi-vcpu guests by treating the vcpus as threads within gdb.  Is there
some other way to look at all the threads' contexts from within gdb?

    J

> Note, you don't need to do anything in tools/debugger/gdb and/or
> gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.
>
> Perhaps, we should just remove tools/debugger/gdb if it's not being
> maintained and no one is using it.
>
> thanks,
> Mukesh
>
>
>
> On Thu, 1 Jul 2010 10:53:31 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
>
>   
>> On Wed, Jun 30, 2010 at 10:16:10PM -0700, Bruce Edge wrote:
>>     
>>> Can one build a usable gdbsx from xen-4.0-testing.hg?
>>>       
>> CC-ing the author - Mukesh.
>>     
>>> Actually a more relevant is, is this still the preferred mechanism
>>> for domU kernel debugging?
>>>
>>> The documentation on building it is a bit out of date and
>>> conflicting.
>>>
>>> This post http://blog.xen.org/index.php/2009/10/21/debugging-on-xen/
>>> States that one needs to use this repo:
>>> http://xenbits.xensource.com/ext/debuggers.hg
>>>
>>> Which looks like hasn't been updated since 4.0 was released as it's
>>> still referencing 4.0-rc
>>>
>>> 0 %> hg clone http://xenbits.xensource.com/ext/debuggers.hg
>>>
>>> destination directory: debuggers.hg
>>> requesting all changes
>>> adding changesets
>>> adding manifests
>>> adding file changes
>>> added 20375 changesets with 117688 changes to 11049 files (+1 heads)
>>> updating working directory
>>> .hgtags@809b20f066fb, line 39: tag '4.0.0-rc1' refers to unknown
>>> node .hgtags@809b20f066fb, line 40: tag '4.0.0-rc2' refers to
>>> unknown node .hgtags@809b20f066fb, line 41: tag '4.0.0-rc3' refers
>>> to unknown node .hgtags@809b20f066fb, line 42: tag '4.0.0-rc4'
>>> refers to unknown node .hgtags@809b20f066fb, line 43: tag
>>> '4.0.0-rc5' refers to unknown node .hgtags@809b20f066fb, line 44:
>>> tag '4.0.0-rc6' refers to unknown node 3164 files updated, 0 files
>>> merged, 0 files removed, 0 files unresolved
>>>
>>> This post: http://zhigang.org/wiki/XenDebugging#xend-debugging
>>> refers to magically generated Oracle images with no information on
>>> how they were created or what sources to use.
>>>
>>> Other posts state that gdbsx has been integrated into
>>> xen-unstable.hg. Does that mean all that's needed to build a debug
>>> enabled xen image is:
>>>
>>> (cd tools/debugger/gdb && ./gdbbuild ) ;
>>> make kdb=y gdbsx=y && make dist
>>>
>>> Thanks
>>>
>>> -Bruce
>>>       
>>     
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>>       
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>   


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