Xen devel - Jul 2010 - State of gdbsx in xen-4.0-testing.hg and debugger documentation.

Can one build a usable gdbsx from xen-4.0-testing.hg?

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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

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. 

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@oracle.com> 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel

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

On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>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.
>
> 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.
>
>
Mukesh,

Thanks for the update, this clarifies a lot and eliminates a all of the
residual chaff from old posting, versions, etc.

-Bruce

> thanks,
> Mukesh
>
>
>
> On Thu, 1 Jul 2010 10:53:31 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
>
>

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

On 01/07/2010 21:13, "Mukesh Rathor" <mukesh.rathor@oracle.com>
wrote:
> 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.
I think that would be a good idea. It''s a decision for Ian or Stefano
(cc''ed) though.

 -- Keir



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

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@oracle.com> 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@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>       
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>   

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

On Thu, 01 Jul 2010 23:54:34 +0200
Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> 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
Hmm... working for me. Can you please run gdbsx with -d and tar
and send output to me?

BTW, what xen and guest versions?

thanks,
M


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

Is there any reason to not build gdbsx by default?

IOW does it affect performance?

-Bruce


On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>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.
>
> 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@oracle.com> 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@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
>
>

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

On 02/07/2010 00:51, "Bruce Edge" <bruce.edge@gmail.com> wrote:
> Is there any reason to not build gdbsx by default?
> 
> IOW does it affect performance?
There''s no reason not to build it always. We could get rid of the
build-time
option.

 -- Keir
> -Bruce
> 
> 
> On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>
> 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.
>> 
>> 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@oracle.com> 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@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>> 
> 
> 


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

On Thu, 1 Jul 2010, Keir Fraser wrote:
> On 01/07/2010 21:13, "Mukesh Rathor"
<mukesh.rathor@oracle.com> wrote:
> 
> > 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.
> 
> I think that would be a good idea. It''s a decision for Ian or
Stefano
> (cc''ed) though.
> 
 
Definitely a good idea

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

On Thu, Jul 1, 2010 at 11:11 PM, Keir Fraser
<keir.fraser@eu.citrix.com>wrote:
> On 02/07/2010 00:51, "Bruce Edge" <bruce.edge@gmail.com>
wrote:
>
> > Is there any reason to not build gdbsx by default?
> >
> > IOW does it affect performance?
>
> There''s no reason not to build it always. We could get rid of the
> build-time
> option.
>
That would simplify the downstream packaging. They wouldn''t need to
provide
an additional mechanism/hook/option to get gdbsx installed.
The current debian packaging patch is a widely used "get this onto my
box"
aid, and it has no facility for tweaking the build options.

-Bruce

>
>  -- Keir
>
> > -Bruce
> >
> >
> > On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>
> > 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.
> >>
> >> 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@oracle.com> 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@lists.xensource.com
> >>>> http://lists.xensource.com/xen-devel
> >>
> >
> >
>
>
>

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

Stefano Stabellini writes ("Re: [Xen-devel] State of gdbsx in
xen-4.0-testing.hg and debugger documentation."):
> On Thu, 1 Jul 2010, Keir Fraser wrote:
> > > Perhaps, we should just remove tools/debugger/gdb if
it''s not being
> > > maintained and no one is using it.
> > 
> > I think that would be a good idea. It''s a decision for Ian or
Stefano
> > (cc''ed) though.
>  
> Definitely a good idea
I''ve committed that removal and it''ll appear in the tools tree
for
Keir to pull from after I''ve dealt with the outstanding patches.

Ian.

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

Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg
and debugger  documentation."):
> That would simplify the downstream packaging. They wouldn''t need
to provide
> an additional mechanism/hook/option to get gdbsx installed.
> The current debian packaging patch is a widely used "get this onto my
box"
> aid, and it has no facility for tweaking the build options.
Sure.  Please submit a patch to wire it into tools/Makefile, or
wherever is appropriate.

Thanks,
Ian.

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

On Fri, Jul 2, 2010 at 9:53 AM, Ian Jackson
<Ian.Jackson@eu.citrix.com>wrote:
> Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in
xen-4.0-testing.hg
> and debugger  documentation."):
> > That would simplify the downstream packaging. They wouldn''t
need to
> provide
> > an additional mechanism/hook/option to get gdbsx installed.
> > The current debian packaging patch is a widely used "get this
onto my
> box"
> > aid, and it has no facility for tweaking the build options.
>
> Sure.  Please submit a patch to wire it into tools/Makefile, or
> wherever is appropriate.
>
> Here is a patch to enable gdbsx by default.
--- xen-4.0-testing.hg-07.02.10/tools/Makefile  2010-07-02
10:30:40.000000000 -0700
+++ xen-4.0-testing.hg/tools/Makefile   2010-07-02 11:25:04.000000000 -0700
@@ -36,6 +36,7 @@
 SUBDIRS-y += libxl
 SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
+SUBDIRS-y += debugger/gdbsx

 # These don''t cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -134,3 +135,8 @@
                $(MAKE) -C ocaml-xenstored clean; \
        fi

+subdir-clean-debugger/gdbsx:
+       $(MAKE) -C debugger/gdbsx clean
+
+subdir-install-debugger/gdbsx:
+       $(MAKE) -C debugger/gdbsx install
--- xen-4.0-testing.hg-07.02.10/xen/Rules.mk    2010-07-02
10:30:41.000000000 -0700
+++ xen-4.0-testing.hg/xen/Rules.mk     2010-07-02 11:58:23.000000000 -0700
@@ -8,7 +8,7 @@
 perfc_arrays  ?= n
 lock_profile  ?= n
 crash_debug   ?= n
-gdbsx         ?= n
+gdbsx         ?= y
 frame_pointer ?= n

 XEN_ROOT=$(BASEDIR)/..

------------cut------------

I suppose it would be cleaner to eliminate the debugger dir as gdbsx is the
only one under there that''s used and that would enable the
tools/Rules.mk
templates to cover the
    subdir-clean-gdbsx:
    subdir-install-gdbsx
targets and not require them to be explicit in tools/Makefile

Also, I don''t know if
    SUBDIRS-y += debugger/gdbsx
should be conditional on any type of target, CONFIG_X86 or?

-Bruce

> Thanks,
> Ian.
>

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

Forgot patch tag in subject ...

On Fri, Jul 2, 2010 at 3:41 PM, Bruce Edge <bruce.edge@gmail.com> wrote:
> On Fri, Jul 2, 2010 at 9:53 AM, Ian Jackson
<Ian.Jackson@eu.citrix.com>wrote:
>
>> Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in
xen-4.0-testing.hg
>> and debugger  documentation."):
>> > That would simplify the downstream packaging. They
wouldn''t need to
>> provide
>> > an additional mechanism/hook/option to get gdbsx installed.
>> > The current debian packaging patch is a widely used "get this
onto my
>> box"
>> > aid, and it has no facility for tweaking the build options.
>>
>> Sure.  Please submit a patch to wire it into tools/Makefile, or
>> wherever is appropriate.
>>
>> Here is a patch to enable gdbsx by default.
>
> --- xen-4.0-testing.hg-07.02.10/tools/Makefile  2010-07-02
> 10:30:40.000000000 -0700
> +++ xen-4.0-testing.hg/tools/Makefile   2010-07-02 11:25:04.000000000 -0700
> @@ -36,6 +36,7 @@
>  SUBDIRS-y += libxl
>  SUBDIRS-y += remus
>  SUBDIRS-$(CONFIG_X86) += xenpaging
> +SUBDIRS-y += debugger/gdbsx
>
>  # These don''t cross-compile
>  ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
> @@ -134,3 +135,8 @@
>                 $(MAKE) -C ocaml-xenstored clean; \
>         fi
>
> +subdir-clean-debugger/gdbsx:
> +       $(MAKE) -C debugger/gdbsx clean
> +
> +subdir-install-debugger/gdbsx:
> +       $(MAKE) -C debugger/gdbsx install
> --- xen-4.0-testing.hg-07.02.10/xen/Rules.mk    2010-07-02
> 10:30:41.000000000 -0700
> +++ xen-4.0-testing.hg/xen/Rules.mk     2010-07-02 11:58:23.000000000 -0700
> @@ -8,7 +8,7 @@
>  perfc_arrays  ?= n
>  lock_profile  ?= n
>  crash_debug   ?= n
> -gdbsx         ?= n
> +gdbsx         ?= y
>  frame_pointer ?= n
>
>  XEN_ROOT=$(BASEDIR)/..
>
> ------------cut------------
>
> I suppose it would be cleaner to eliminate the debugger dir as gdbsx is the
> only one under there that''s used and that would enable the
tools/Rules.mk
> templates to cover the
>     subdir-clean-gdbsx:
>     subdir-install-gdbsx
> targets and not require them to be explicit in tools/Makefile
>
> Also, I don''t know if
>     SUBDIRS-y += debugger/gdbsx
> should be conditional on any type of target, CONFIG_X86 or?
>
> -Bruce
>
>
>> Thanks,
>> Ian.
>>
>
>

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

Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg
and debugger  documentation."):
> Here is a patch to enable gdbsx by default.
Thanks.  Is it against 4.0-testing as it seems to be ?  I think we
probably want this against xen-unstable, against which your patch
doesn''t apply.
> I suppose it would be cleaner to eliminate the debugger dir as gdbsx is the
> only one under there that''s used and that would enable the
tools/Rules.mk
> templates to cover the
>     subdir-clean-gdbsx:
>     subdir-install-gdbsx
> targets and not require them to be explicit in tools/Makefile
Well, yes, until we got another debugger again.
> Also, I don''t know if
>     SUBDIRS-y += debugger/gdbsx
> should be conditional on any type of target, CONFIG_X86 or?
I''m happy to enable it and get the people who find it breaks to
tell us what conditions mean it needs to be disabled :-).

Ian.

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

On Tue, Jul 6, 2010 at 4:57 AM, Ian Jackson
<Ian.Jackson@eu.citrix.com>wrote:
> Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in
xen-4.0-testing.hg
> and debugger  documentation."):
> > Here is a patch to enable gdbsx by default.
>
> Thanks.  Is it against 4.0-testing as it seems to be ?

Yes, it is.

> I think we
> probably want this against xen-unstable, against which your patch
> doesn''t apply.
>
OK, I''ll pull down an unstable tree and resubmit.

Thanks for the help.

-Bruce

>
> > I suppose it would be cleaner to eliminate the debugger dir as gdbsx
is
> the
> > only one under there that''s used and that would enable the
tools/Rules.mk
> > templates to cover the
> >     subdir-clean-gdbsx:
> >     subdir-install-gdbsx
> > targets and not require them to be explicit in tools/Makefile
>
> Well, yes, until we got another debugger again.
>
> > Also, I don''t know if
> >     SUBDIRS-y += debugger/gdbsx
> > should be conditional on any type of target, CONFIG_X86 or?
>
> I''m happy to enable it and get the people who find it breaks to
> tell us what conditions mean it needs to be disabled :-).
>
> Ian.
>

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

On Tue, Jul 6, 2010 at 4:57 AM, Ian Jackson
<Ian.Jackson@eu.citrix.com>wrote:
> Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in
xen-4.0-testing.hg
> and debugger  documentation."):
> > Here is a patch to enable gdbsx by default.
>
> Thanks.  Is it against 4.0-testing as it seems to be ?  I think we
> probably want this against xen-unstable, against which your patch
> doesn''t apply.
>
Ian, here''s an unstable patch:

diff -Naur xen-unstable.hg-2010-07-06/tools/Makefile
xen-unstable.hg/tools/Makefile
--- xen-unstable.hg-2010-07-06/tools/Makefile   2010-07-06
14:40:54.000000000 -0700
+++ xen-unstable.hg/tools/Makefile      2010-07-06 16:15:15.000000000 -0700
@@ -35,6 +35,7 @@
 SUBDIRS-y += libxl
 SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
+SUBDIRS-y += debugger/gdbsx

 # These don''t cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -114,3 +115,9 @@
                $(buildmakevars2shellvars); \
                $(MAKE) -C ioemu-dir clean; \
        fi
+
+subdir-clean-debugger/gdbsx:
+       $(MAKE) -C debugger/gdbsx clean
+
+subdir-install-debugger/gdbsx:
+       $(MAKE) -C debugger/gdbsx install

-------------cut----------------

Thanks

-Bruce

> > I suppose it would be cleaner to eliminate the debugger dir as gdbsx
is
> the
> > only one under there that''s used and that would enable the
tools/Rules.mk
> > templates to cover the
> >     subdir-clean-gdbsx:
> >     subdir-install-gdbsx
> > targets and not require them to be explicit in tools/Makefile
>
> Well, yes, until we got another debugger again.
>
> > Also, I don''t know if
> >     SUBDIRS-y += debugger/gdbsx
> > should be conditional on any type of target, CONFIG_X86 or?
>
> I''m happy to enable it and get the people who find it breaks to
> tell us what conditions mean it needs to be disabled :-).
>
> Ian.
>

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

Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg
and debugger  documentation."):
> Ian, here''s an unstable patch:
Thanks.  It still didn''t apply to xen-unstable because it had had tabs
replaced with spaces, but I fixed it up.

And finally - sorry for not spotting this before - you should submit
your next patch with a Signed-off-by line like this:
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
except with your name and email address.  This indicates that you are
certifying the code as suitable (copyright-wise and so on) for
inclusion in Xen.  You can find the precise meaning in the Linux
upstream kernel tree (Documentation/SubmittingPatches, copy below).

In this case, and since your patch was so small, I took your messages
to grant the relevant permissions.

Thanks,
Ian.
>From Documentation/SubmittingPatches:
        Developer''s Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

        (d) I understand and agree that this project and the contribution
            are public and that a record of the contribution (including all
            personal information I submit with it, including my sign-off) is
            maintained indefinitely and may be redistributed consistent with
            this project or the open source license(s) involved.

-- 

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

On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge <bruce.edge@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>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.
>>
>> 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.
>>
>>
>
I think there''s something wrong with the docs for gdbsx regarding
module
debugging.

The docs for using gdbsx state:

   - Additionally, to debug loadable kernel modules, please do following:
      (gdb) p init_mm.pgd[3]
      $1 = {pgd = 0x1b874f027}
      (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
      pgd3val set to: 0x1b874f027

When I try to use this to access a module, I get:

(gdb) p init_mm.pgd[3]
$10 = {pgd = 0}
(gdb)

I assume that the value of pgd should not be 0 as the makes the next command
it the docs meaningless.

Is it possible that the field [3] offset has changed?
What field are we after with this command?

Here''s the full struct:

(gdb) p init_mm
$2 = {mmap = 0x0, mm_rb = {rb_node = 0x0}, mmap_cache = 0x0,
get_unmapped_area = 0, unmap_area = 0, mmap_base = 0, task_size = 0,
cached_hole_size = 0, free_area_cache = 0,
  pgd = 0xffffffff81001000, mm_users = {counter = 2}, mm_count = {counter 15},
map_count = 0, mmap_sem = {count = 0, wait_lock = {raw_lock = {{slock 0, tickets
= {head = 0 ''\0'',
            tail = 0 ''\0''}}, waiting = 0
''\0''}}, wait_list = {next 0xffffffff81952ed0, prev =
0xffffffff81952ed0}}, page_table_lock = {raw_lock
= {{slock = 4369, tickets = {
          head = 17 ''\021'', tail = 17
''\021''}}, waiting = 0 ''\0''}}, mmlist {next =
0xffffffff81952ee8, prev = 0xffffffff81952ee8}, _file_rss = {counter
= 0}, _anon_rss = {counter = 0},
  hiwater_rss = 0, hiwater_vm = 0, total_vm = 0, locked_vm = 0, shared_vm 0,
exec_vm = 0, stack_vm = 0, reserved_vm = 0, def_flags = 0, nr_ptes = 0,
start_code = 18446744071578845184,
  end_code = 18446744071585415526, start_data = 0, end_data
18446744071589170120, start_brk = 0, brk = 18446744071591583744, start_stack
= 0, arg_start = 0, arg_end = 0, env_start = 0,
  env_end = 0, saved_auxv = {0 <repeats 44 times>}, binfmt = 0x0,
cpu_vm_mask = {bits = {18446744073709551598}}, context = {ldt = 0x0, size 0,
lock = {count = {counter = 0}, wait_lock = {
        raw_lock = {{slock = 0, tickets = {head = 0 ''\0'', tail
= 0 ''\0''}},
waiting = 0 ''\0''}}, wait_list = {next = 0x0, prev = 0x0},
owner = 0x0}, vdso
= 0x0, has_foreign_mappings = 0},
  faultstamp = 0, token_priority = 0, last_interval = 0, flags = 0,
core_state = 0x0, ioctx_lock = {raw_lock = {{slock = 0, tickets = {head = 0
''\0'', tail = 0 ''\0''}}, waiting = 0
''\0''}},
  ioctx_list = {first = 0x0}, owner = 0xffffffff81940600, exe_file = 0x0,
num_exe_file_vmas = 0, mmu_notifier_mm = 0x0}

This is with xen-unstable sync''d a few hours ago.


Thanks

-Bruce

> Mukesh,
>
> Thanks for the update, this clarifies a lot and eliminates a all of the
> residual chaff from old posting, versions, etc.
>
> -Bruce
>
>
>> thanks,
>> Mukesh
>>
>>
>>
>> On Thu, 1 Jul 2010 10:53:31 -0400
>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@lists.xensource.com
>> > > http://lists.xensource.com/xen-devel
>>
>>
>

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

On Tue, Jul 13, 2010 at 10:29 PM, Bruce Edge <bruce.edge@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge <bruce.edge@gmail.com>
wrote:
>
>> On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>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.
>>>
>>> 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.
>>>
>>>
>>
> I think there''s something wrong with the docs for gdbsx regarding
module
> debugging.
>
> The docs for using gdbsx state:
>
>    - Additionally, to debug loadable kernel modules, please do following:
>       (gdb) p init_mm.pgd[3]
>       $1 = {pgd = 0x1b874f027}
>       (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
>       pgd3val set to: 0x1b874f027
>
> When I try to use this to access a module, I get:
>
> (gdb) p init_mm.pgd[3]
> $10 = {pgd = 0}
> (gdb)
>
> I assume that the value of pgd should not be 0 as the makes the next
> command it the docs meaningless.
>
> Is it possible that the field [3] offset has changed?
> What field are we after with this command?
>
> Here''s the full struct:
>
> (gdb) p init_mm
> $2 = {mmap = 0x0, mm_rb = {rb_node = 0x0}, mmap_cache = 0x0,
> get_unmapped_area = 0, unmap_area = 0, mmap_base = 0, task_size = 0,
> cached_hole_size = 0, free_area_cache = 0,
>   pgd = 0xffffffff81001000, mm_users = {counter = 2}, mm_count = {counter
> 15}, map_count = 0, mmap_sem = {count = 0, wait_lock = {raw_lock = {{slock
> 0, tickets = {head = 0 ''\0'',
>             tail = 0 ''\0''}}, waiting = 0
''\0''}}, wait_list = {next > 0xffffffff81952ed0, prev =
0xffffffff81952ed0}}, page_table_lock = {raw_lock
> = {{slock = 4369, tickets = {
>           head = 17 ''\021'', tail = 17
''\021''}}, waiting = 0 ''\0''}}, mmlist
> = {next = 0xffffffff81952ee8, prev = 0xffffffff81952ee8}, _file_rss >
{counter = 0}, _anon_rss = {counter = 0},
>   hiwater_rss = 0, hiwater_vm = 0, total_vm = 0, locked_vm = 0, shared_vm
> 0, exec_vm = 0, stack_vm = 0, reserved_vm = 0, def_flags = 0, nr_ptes = 0,
> start_code = 18446744071578845184,
>   end_code = 18446744071585415526, start_data = 0, end_data >
18446744071589170120, start_brk = 0, brk = 18446744071591583744, start_stack
> = 0, arg_start = 0, arg_end = 0, env_start = 0,
>   env_end = 0, saved_auxv = {0 <repeats 44 times>}, binfmt = 0x0,
> cpu_vm_mask = {bits = {18446744073709551598}}, context = {ldt = 0x0, size
> 0, lock = {count = {counter = 0}, wait_lock = {
>         raw_lock = {{slock = 0, tickets = {head = 0 ''\0'',
tail = 0 ''\0''}},
> waiting = 0 ''\0''}}, wait_list = {next = 0x0, prev = 0x0},
owner = 0x0}, vdso
> = 0x0, has_foreign_mappings = 0},
>   faultstamp = 0, token_priority = 0, last_interval = 0, flags = 0,
> core_state = 0x0, ioctx_lock = {raw_lock = {{slock = 0, tickets = {head = 0
> ''\0'', tail = 0 ''\0''}}, waiting = 0
''\0''}},
>   ioctx_list = {first = 0x0}, owner = 0xffffffff81940600, exe_file = 0x0,
> num_exe_file_vmas = 0, mmu_notifier_mm = 0x0}
>
> This is with xen-unstable sync''d a few hours ago.
>
>
> Thanks
>
> -Bruce
>
>


Additionally, there''s a problem with the macros in the docs too. After
sourcing them, the ps command makes gdb exit:

(gdb) source /users/bedge/macros.gdb
(gdb) ps
Pointer       PID      Command
/build/buildd/gdb-6.8/gdb/printcmd.c:2261: internal-error: printf_command:
Assertion `*p == ''p'' && *(p + 1) ==
''\0'''' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/build/buildd/gdb-6.8/gdb/printcmd.c:2261: internal-error: printf_command:
Assertion `*p == ''p'' && *(p + 1) ==
''\0'''' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
zsh: abort      gdb ./vmlinux

-Bruce


> Mukesh,
>>
>
>> Thanks for the update, this clarifies a lot and eliminates a all of the
>> residual chaff from old posting, versions, etc.
>>
>> -Bruce
>>
>>
>>> thanks,
>>> Mukesh
>>>
>>>
>>>
>>> On Thu, 1 Jul 2010 10:53:31 -0400
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@lists.xensource.com
>>> > > http://lists.xensource.com/xen-devel
>>>
>>>
>>
>

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

On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor
<mukesh.rathor@oracle.com>wrote:
> On Thu, 01 Jul 2010 23:54:34 +0200
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> > 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
>
> Hmm... working for me. Can you please run gdbsx with -d and tar
> and send output to me?
>
> Mukesh,
Here''s the output from gdbsx -d when trying to view CPUs as thread.


> BTW, what xen and guest versions?
>
xen 4.1 unstable sync''d last night
dom0:  Linux kaan-22 2.6.32.16 #1 SMP Mon Jul 12 14:00:17 UTC 2010 x86_64
GNU/Linux
domU: Same: Linux kaan-22 2.6.32.16 #1 SMP Mon Jul 12 14:00:17 UTC 2010
x86_64 GNU/Linux

Thanks for looking into this.

-Bruce

> thanks,
> M
>
>


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

On Tue, 13 Jul 2010 22:29:48 -0700
Bruce Edge <bruce.edge@gmail.com> wrote:
> The docs for using gdbsx state:
> 
>    - Additionally, to debug loadable kernel modules, please do
> following: (gdb) p init_mm.pgd[3]
>       $1 = {pgd = 0x1b874f027}
>       (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
>       pgd3val set to: 0x1b874f027
> 
> When I try to use this to access a module, I get:
> 
> (gdb) p init_mm.pgd[3]
> $10 = {pgd = 0}
> (gdb)
> 
> I assume that the value of pgd should not be 0 as the makes the next
> command it the docs meaningless.
> 
> Is it possible that the field [3] offset has changed?
> What field are we after with this command?
> 
Bruce,

This for 32bit domU kernel only. I guess the README is not updated in
all trees.. I''ll submit patch to do this.

Thanks,
Mukesh


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

> 
> Additionally, there''s a problem with the macros in the docs too.
After
> sourcing them, the ps command makes gdb exit:
> 
> (gdb) source /users/bedge/macros.gdb
> (gdb) ps
> Pointer       PID      Command
> /build/buildd/gdb-6.8/gdb/printcmd.c:2261: internal-error:
> printf_command: Assertion `*p == ''p'' && *(p + 1)
== ''\0'''' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) [answered Y; input not from
> terminal] /build/buildd/gdb-6.8/gdb/printcmd.c:2261: internal-error:
> printf_command: Assertion `*p == ''p'' && *(p + 1)
== ''\0'''' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) [answered Y; input not from
> terminal] zsh: abort      gdb ./vmlinux

Seems to be a gdb bug. Replace:

printf "%-14p%-9d%s\n", $task_entry, $task_entry->pid,
$task_entry->comm

with 

printf "%p %-9d%s\n", $task_entry, $task_entry->pid,
$task_entry->comm


Mukesh



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

On Wed, 14 Jul 2010 07:29:46 -0700
Bruce Edge <bruce.edge@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor
> <mukesh.rathor@oracle.com>wrote:
> 
> > On Thu, 01 Jul 2010 23:54:34 +0200
> > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >
> > > 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?
> > >
> > Hmm... working for me. Can you please run gdbsx with -d and tar
> > and send output to me?
> >
> > Mukesh,
> 
> Here''s the output from gdbsx -d when trying to view CPUs as
thread.

Again, looks like gdb issue. I can reproduce with gdb version 
''GNU gdb (GDB) Fedora (7.0.1-45.fc12)''.  However, things are
fine
with gdb 6.* versions. I looked at gdbsx and it seems to be doing
the right thing. So someone more familiar with gdb will have to debug
it. For now, I hope you can use older 6* gdb, assuming you are using
newer 7.* version.

thanks
Mukesh


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

On Wed, 14 Jul 2010 16:17:16 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Wed, 14 Jul 2010 07:29:46 -0700
> Bruce Edge <bruce.edge@gmail.com> wrote:
> 
> > On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor
> > <mukesh.rathor@oracle.com>wrote:
> > 
> > > On Thu, 01 Jul 2010 23:54:34 +0200
> > > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > >
> > > > 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?
> > > >
> > > Hmm... working for me. Can you please run gdbsx with -d and tar
> > > and send output to me?
> > >
> > > Mukesh,
> > 
> > Here''s the output from gdbsx -d when trying to view CPUs as
thread.
> 
> 
> Again, looks like gdb issue. I can reproduce with gdb version 
> ''GNU gdb (GDB) Fedora (7.0.1-45.fc12)''.  However, things
are fine
> with gdb 6.* versions. I looked at gdbsx and it seems to be doing
> the right thing. So someone more familiar with gdb will have to debug
> it. For now, I hope you can use older 6* gdb, assuming you are using
> newer 7.* version.


I see why version 7* isn''t working. The function remote_threads_info()
in gdb has changed from version 6. It used to do strtoul to parse
thread ids in ''m 0,1,2l'', but it doesn''t now. The new
code seems to have
bug where space after ''m'' is not skipped, which strtoul() did.

Anwyays, I can work around it by getting rid of the space. I thought
it was required because that''s the way it''s in the gdb
manual...

I''m submitting a patch, if you''ll please try out. The warning
''warning:
Couldn''t restore frame #0'' if you get it, seems harmless.


thanks,
Mukesh




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

On Wed, Jul 14, 2010 at 2:10 PM, Mukesh Rathor <mukesh.rathor@oracle.com>
wrote:
>
>
> On Tue, 13 Jul 2010 22:29:48 -0700
> Bruce Edge <bruce.edge@gmail.com> wrote:
>> The docs for using gdbsx state:
>>
>>    - Additionally, to debug loadable kernel modules, please do
>> following: (gdb) p init_mm.pgd[3]
>>       $1 = {pgd = 0x1b874f027}
>>       (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
>>       pgd3val set to: 0x1b874f027
>>
>> When I try to use this to access a module, I get:
>>
>> (gdb) p init_mm.pgd[3]
>> $10 = {pgd = 0}
>> (gdb)
>>
>> I assume that the value of pgd should not be 0 as the makes the next
>> command it the docs meaningless.
>>
>> Is it possible that the field [3] offset has changed?
>> What field are we after with this command?
>>
>
> Bruce,
>
> This for 32bit domU kernel only. I guess the README is not updated in
> all trees.. I''ll submit patch to do this.
>
> Thanks,
> Mukesh
>
>
Mukesh,
I''m getting back to working on the debugger and have not been able to
use it with any modules. How does one set breakpoints for modules that
are not loaded?
This may be a lack of experience with kernel/gdb context, but how does
one go about setting a breakpoint in a module''s init code?
Is there any method to use to put in a symbolic function name as a
breakpoint for a module that is not yet loaded?

Are there any tutorials illustrating the use of gdbsx with a custom
kernel module? This would be most helpful.

Thanks

-Bruce

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

On Tue, 28 Sep 2010 09:55:59 -0700
Bruce Edge <bruce.edge@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 2:10 PM, Mukesh Rathor
> <mukesh.rathor@oracle.com> wrote:
> >
> >
> > On Tue, 13 Jul 2010 22:29:48 -0700
> > Bruce Edge <bruce.edge@gmail.com> wrote:
> >> The docs for using gdbsx state:
> >>
> >>    - Additionally, to debug loadable kernel modules, please do
> >> following: (gdb) p init_mm.pgd[3]
> >>       $1 = {pgd = 0x1b874f027}
> >>       (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
> >>       pgd3val set to: 0x1b874f027
> >>
> >> When I try to use this to access a module, I get:
> >>
> >> (gdb) p init_mm.pgd[3]
> >> $10 = {pgd = 0}
> >> (gdb)
> >>
> >> I assume that the value of pgd should not be 0 as the makes the
> >> next command it the docs meaningless.
> >>
> >> Is it possible that the field [3] offset has changed?
> >> What field are we after with this command?
> >>
> >
> > Bruce,
> >
> > This for 32bit domU kernel only. I guess the README is not updated
> > in all trees.. I''ll submit patch to do this.
> >
> > Thanks,
> > Mukesh
> >
> >
> 
> Mukesh,
> I''m getting back to working on the debugger and have not been able
to
> use it with any modules. How does one set breakpoints for modules that
> are not loaded?
You cannot.
> This may be a lack of experience with kernel/gdb context, but how does
> one go about setting a breakpoint in a module''s init code?
> Is there any method to use to put in a symbolic function name as a
> breakpoint for a module that is not yet loaded?
Set breakpoint in kernel load module function, and step from there. 
> Are there any tutorials illustrating the use of gdbsx with a custom
> kernel module? This would be most helpful.
Nop, not at present.

Mukesh





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