From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Wed, 30 Jun 2010 22:16:10 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1583708436==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1583708436== Content-Type: multipart/alternative; boundary=0016e64766348d59a3048a4c9111 --0016e64766348d59a3048a4c9111 Content-Type: text/plain; charset=ISO-8859-1 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 --0016e64766348d59a3048a4c9111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can one build a usable gdbsx from=A0xen-4.0-testing.hg?

=
Actually a more relevant is, is this still the preferred mechani= sm 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/1= 0/21/debugging-on-xen/
States that one needs to use this repo: http://xenbits.xensource.com/ext/d= ebuggers.hg

Which looks like hasn't been u= pdated since 4.0 was released as it's still referencing 4.0-rc=A0


destination directory: debuggers= .hg
requesting all changes
adding changesets
adding manifests
adding file cha= nges
added 20375 changesets with 117688 changes to 11049 files (+= 1 heads)
updating working directory
.hgtags@809b20f066f= b, line 39: tag '4.0.0-rc1' refers to unknown node
.hgtags@809b20f066fb, line 40: tag '4.0.0-rc2' refers to unkno= wn node
.hgtags@809b20f066fb, line 41: tag '4.0.0-rc3' re= fers 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 unkno= wn node
.hgtags@809b20f066fb, line 44: tag '4.0.0-rc6' re= fers to unknown node
3164 files updated, 0 files merged, 0 files = removed, 0 files unresolved

refers to magically generated Oracle images with no information on how= they were created or what sources to use.

Other p= osts state that gdbsx has been integrated into xen-unstable.hg.=A0
Does that mean=A0all that's needed to build a debug enabled xen im= age is:

(cd tools/debugger/gdb && ./g= dbbuild ) ;=A0
mak= e kdb=3Dy gdbsx=3Dy && make dist

Thanks

-Bruce
--0016e64766348d59a3048a4c9111-- --===============1583708436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1583708436==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 1 Jul 2010 10:53:31 -0400 Message-ID: <20100701145331.GC31947@phenom.dumpdata.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge , mukesh.rathor@oracle.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 1 Jul 2010 13:13:36 -0700 Message-ID: <20100701131336.5409f873@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100701145331.GC31947@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, Bruce Edge List-Id: xen-devel@lists.xenproject.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 1 Jul 2010 13:47:22 -0700 Message-ID: References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0470358291==" Return-path: In-Reply-To: <20100701131336.5409f873@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============0470358291== Content-Type: multipart/alternative; boundary=0016369fa1bcbbe988048a599391 --0016369fa1bcbbe988048a599391 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 1, 2010 at 1: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. > > 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 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 > > --0016369fa1bcbbe988048a599391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor <mukesh.rath= or@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=3Dy =A0is 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. =A0tools/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,

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

-Bruce
=A0
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 mechanis= m
> > 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 a= s 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 hea= ds)
> > 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' refer= s to
> > unknown node .hgtags@809b20f066fb, line 41: tag '4.0.0-rc3= 9; 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-debug= ging
> > refers to magically generated Oracle images with no information o= n
> > 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=3Dy gdbsx=3Dy && make dist
> >
> > Thanks
> >
> > -Bruce
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.= xensource.com
> > http://lists.xensource.com/xen-devel


--0016369fa1bcbbe988048a599391-- --===============0470358291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0470358291==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 1 Jul 2010 21:48:37 +0100 Message-ID: References: <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100701131336.5409f873@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor , Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xensource.com" , Stabellini , Bruce, Ian Jackson , Edge Stefano List-Id: xen-devel@lists.xenproject.org On 01/07/2010 21:13, "Mukesh Rathor" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 01 Jul 2010 23:54:34 +0200 Message-ID: <4C2D0E9A.4010100@goop.org> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100701131336.5409f873@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel@lists.xensource.com, Bruce Edge , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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 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 > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 1 Jul 2010 15:08:02 -0700 Message-ID: <20100701150802.54bad0ef@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> <4C2D0E9A.4010100@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C2D0E9A.4010100@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, Bruce Edge , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Thu, 01 Jul 2010 23:54:34 +0200 Jeremy Fitzhardinge 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 1 Jul 2010 16:51:30 -0700 Message-ID: References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0500899344==" Return-path: In-Reply-To: <20100701131336.5409f873@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============0500899344== Content-Type: multipart/alternative; boundary=00504502e23d40e84e048a5c266a --00504502e23d40e84e048a5c266a Content-Type: text/plain; charset=ISO-8859-1 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 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 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 > > --00504502e23d40e84e048a5c266a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there any reason to not build gdbsx by default?

IOW d= oes it affect performance?

-Bruce


On Thu, Jul 1, 2010 at 1:13 PM, Mukesh R= athor <muk= esh.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=3Dy =A0is 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. =A0tools/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 mechanis= m
> > 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 a= s 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 hea= ds)
> > 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' refer= s to
> > unknown node .hgtags@809b20f066fb, line 41: tag '4.0.0-rc3= 9; 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-debug= ging
> > refers to magically generated Oracle images with no information o= n
> > 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=3Dy gdbsx=3Dy && make dist
> >
> > Thanks
> >
> > -Bruce
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.= xensource.com
> > http://lists.xensource.com/xen-devel


--00504502e23d40e84e048a5c266a-- --===============0500899344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0500899344==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 07:11:19 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge , Mukesh Rathor Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 02/07/2010 00:51, "Bruce Edge" wrote: > Is there any reason to not build gdbsx by default? >=20 > IOW does it affect performance? There's no reason not to build it always. We could get rid of the build-tim= e option. -- Keir > -Bruce >=20 >=20 > On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor > wrote: >> Thanks for CC Konrad, I'm gazillions postings behind in catching up >> xen-devel. >>=20 >> Bruce, you don't need to use the ext repo anymore as gdbsx is now >> merged mainline. I should update the blog post. >>=20 >> To build a debug enabled xen image: make gdbsx=3Dy =A0is all you need >> to do. After booting with gdbsx enabled xen, you can run gdbsx in >> dom0. See tools/debugger/gdbsx/README. >>=20 >> Note, you don't need to do anything in tools/debugger/gdb and/or >> gdbbuild. =A0tools/debugger/gdb (gdbbuild) is unlreated to gdbsx. >>=20 >> Perhaps, we should just remove tools/debugger/gdb if it's not being >> maintained and no one is using it. >>=20 >> thanks, >> Mukesh >>=20 >>=20 >>=20 >> On Thu, 1 Jul 2010 10:53:31 -0400 >> Konrad Rzeszutek Wilk wrote: >>=20 >>> 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? >>>=20 >>> CC-ing the author - Mukesh. >>>>=20 >>>> Actually a more relevant is, is this still the preferred mechanism >>>> for domU kernel debugging? >>>>=20 >>>> The documentation on building it is a bit out of date and >>>> conflicting. >>>>=20 >>>> 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 >>>>=20 >>>> Which looks like hasn't been updated since 4.0 was released as it's >>>> still referencing 4.0-rc >>>>=20 >>>> 0 %> hg clone http://xenbits.xensource.com/ext/debuggers.hg >>>>=20 >>>> 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 >>>>=20 >>>> 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. >>>>=20 >>>> 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: >>>>=20 >>>> (cd tools/debugger/gdb && ./gdbbuild ) ; >>>> make kdb=3Dy gdbsx=3Dy && make dist >>>>=20 >>>> Thanks >>>>=20 >>>> -Bruce >>>=20 >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>=20 >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 11:45:07 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian, Konrad Rzeszutek Wilk , Stefano Stabellini , Jackson , Bruce Edge , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 1 Jul 2010, Keir Fraser wrote: > On 01/07/2010 21:13, "Mukesh Rathor" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 06:11:37 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0682540797==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============0682540797== Content-Type: multipart/alternative; boundary=e0cb4e887e87b34db6048a67534d --e0cb4e887e87b34db6048a67534d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 1, 2010 at 11:11 PM, Keir Fraser wrote: > On 02/07/2010 00:51, "Bruce Edge" 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 > > 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 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 > >> > > > > > > > --e0cb4e887e87b34db6048a67534d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 downstr= eam packaging. They wouldn't need to provide an additional mechanism/ho= ok/option to get gdbsx installed.=A0
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
=A0

=A0-- 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 catchi= ng 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=3Dy =A0is all you n= eed
>> to do. After booting with gdbsx enabled xen, you can run gdbsx in<= br> >> dom0. See tools/debugger/gdbsx/README.
>>
>> Note, you don't need to do anything in tools/debugger/gdb and/= or
>> gdbbuild. =A0tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.<= br> >>
>> 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 m= echanism
>>>> for domU kernel debugging?
>>>>
>>>> The documentation on building it is a bit out of date and<= br> >>>> 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 rel= eased as it's
>>>> still referencing 4.0-rc
>>>>
>>>> 0 %> hg clone http://xenbits.xensource.com/ext/debugge= rs.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' ref= ers 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<= br> >>>> '4.0.0-rc5' refers to unknown node .hgtags@809b20f= 066fb, 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#xen= d-debugging
>>>> refers to magically generated Oracle images with no inform= ation 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 b= uild a debug
>>>> enabled xen image is:
>>>>
>>>> (cd tools/debugger/gdb && ./gdbbuild ) ;
>>>> make kdb=3Dy gdbsx=3Dy && make dist
>>>>
>>>> Thanks
>>>>
>>>> -Bruce
>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel= @lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>
>
>



--e0cb4e887e87b34db6048a67534d-- --===============0682540797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0682540797==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 17:52:16 +0100 Message-ID: <19502.6464.713226.810542@mariner.uk.xensource.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Bruce Edge , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 17:53:36 +0100 Message-ID: <19502.6544.743563.733900@mariner.uk.xensource.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 15:41:06 -0700 Message-ID: References: <19502.6544.743563.733900@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1261985692==" Return-path: In-Reply-To: <19502.6544.743563.733900@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============1261985692== Content-Type: multipart/alternative; boundary=0016e68ee95a5a58f4048a6f48b3 --0016e68ee95a5a58f4048a6f48b3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 2, 2010 at 9:53 AM, Ian Jackson 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. > --0016e68ee95a5a58f4048a6f48b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 =A0documentation."):
> That would simplify the downstream packaging. They w= ouldn't need to provide
> an additional mechanism/hook/option to get gdbsx installed.
> The current debian packaging patch is a widely used "get this ont= o my box"
> aid, and it has no facility for tweaking the build options.

Sure. =A0Please 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 =A02010= -07-02 10:30:40.000000000 -0700
+++ xen-4.0-testing.hg/tools/Make= file =A0 2010-07-02 11:25:04.000000000 -0700
@@ -36,6 +36,7 @@
=A0SUBDIRS-y +=3D libxl
=A0SUBDI= RS-y +=3D remus
=A0SUBDIRS-$(CONFIG_X86) +=3D xenpaging
+SUBDIRS-y +=3D debugger/gdbsx
=A0
=A0# These don'= t cross-compile
=A0ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -134,3 += 135,8 @@
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$(MAKE) -C ocaml-xenst= ored clean; \
=A0=A0 =A0 =A0 =A0fi
=A0
+subdi= r-clean-debugger/gdbsx:
+ =A0 =A0 =A0 $(MAKE) -C debugger/gdbsx clean
+
+s= ubdir-install-debugger/gdbsx:
+ =A0 =A0 =A0 $(MAKE) -C debugger/g= dbsx install
--- xen-4.0-testing.hg-07.02.10/xen/Rules.mk =A0 =A0= 2010-07-02 10:30:41.000000000 -0700
+++ xen-4.0-testing.hg/xen/Rules.mk =A0 =A0 2010-07-02 11:58:23.000000= 000 -0700
@@ -8,7 +8,7 @@
=A0perfc_arrays =A0?=3D n
=A0lock_profile =A0?=3D n
=A0crash_debug =A0 ?=3D n
<= div>-gdbsx =A0 =A0 =A0 =A0 ?=3D n
+gdbsx =A0 =A0 =A0 =A0 ?=3D y
=A0frame_pointer ?=3D n
<= div>=A0
=A0XEN_ROOT=3D$(BASEDIR)/..

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

I suppose it would b= e cleaner to eliminate the debugger dir as gdbsx is the only one under ther= e that's used and that would enable the tools/Rules.mk templates to cov= er the=A0
=A0=A0 =A0subdir-clean-gdbsx:
=A0=A0 =A0subdir-install-= gdbsx
targets and not require them to be explicit in tools/= Makefile

Also, I don't know if=A0
= =A0=A0 =A0SUBDIRS-y +=3D debugger/gdbsx
should be conditional on any type of target, CONFIG_X86 or?
=
-Bruce
=A0
Thanks,
Ian.

--0016e68ee95a5a58f4048a6f48b3-- --===============1261985692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1261985692==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: [PATCH] State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Fri, 2 Jul 2010 16:43:57 -0700 Message-ID: References: <19502.6544.743563.733900@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0815932873==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============0815932873== Content-Type: multipart/alternative; boundary=0016e64cad1e18f908048a7029d6 --0016e64cad1e18f908048a7029d6 Content-Type: text/plain; charset=ISO-8859-1 Forgot patch tag in subject ... On Fri, Jul 2, 2010 at 3:41 PM, Bruce Edge wrote: > On Fri, Jul 2, 2010 at 9:53 AM, Ian Jackson 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. >> > > --0016e64cad1e18f908048a7029d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Forgot patch tag in subject ...

On Fri, Jul 2, 2010 at 3:41 PM, Bruce Edge <bruce.edge@gmail.com> wrot= e:
=
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 =A0documentation."):
> That would simplify the downstream packaging. They wouldn't n= eed to provide
> an additional mechanism/hook/option to get gdbsx installed.
> The current debian packaging patch is a widely used "get this ont= o my box"
> aid, and it has no facility for tweaking the build options.

Sure. =A0Please submit a patch to wire it into tools/Makefile, or
wherever is appropriate.

Here is a patch to enable gdbsx by defaul= t.

--- xen-4.0-testing.hg-07.02.10/tools/Make= file =A02010-07-02 10:30:40.000000000 -0700
+++ xen-4.0-testing.h= g/tools/Makefile =A0 2010-07-02 11:25:04.000000000 -0700
@@ -36,6 +36,7 @@
=A0SUBDIRS-y +=3D libxl
=A0SUBDI= RS-y +=3D remus
=A0SUBDIRS-$(CONFIG_X86) +=3D xenpaging
+SUBDIRS-y +=3D debugger/gdbsx
=A0
=A0# These don'= t cross-compile
=A0ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -134,3 += 135,8 @@
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$(MAKE) -C ocaml-xenst= ored clean; \
=A0=A0 =A0 =A0 =A0fi
=A0
+subdi= r-clean-debugger/gdbsx:
+ =A0 =A0 =A0 $(MAKE) -C debugger/gdbsx clean
+
+s= ubdir-install-debugger/gdbsx:
+ =A0 =A0 =A0 $(MAKE) -C debugger/g= dbsx install
--- xen-4.0-testing.hg-07.02.10/xen/Rules.mk =A0 =A0= 2010-07-02 10:30:41.000000000 -0700
+++ xen-4.0-testing.hg/xen/Rules.mk =A0 =A0 2010-07-02 11:58:23.000000= 000 -0700
@@ -8,7 +8,7 @@
=A0perfc_arrays =A0?=3D n
=A0lock_profile =A0?=3D n
=A0crash_debug =A0 ?=3D n
<= div>-gdbsx =A0 =A0 =A0 =A0 ?=3D n
+gdbsx =A0 =A0 =A0 =A0 ?=3D y
=A0frame_pointer ?=3D n
<= div>=A0
=A0XEN_ROOT=3D$(BASEDIR)/..

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

I suppose it would b= e cleaner to eliminate the debugger dir as gdbsx is the only one under ther= e that's used and that would enable the tools/Rules.mk templates to cov= er the=A0
=A0=A0 =A0subdir-clean-gdbsx:
=A0=A0 =A0subdir-install-= gdbsx
targets and not require them to be explicit in tools/= Makefile

Also, I don't know if=A0
= =A0=A0 =A0SUBDIRS-y +=3D debugger/gdbsx
should be conditional on any type of target, CONFIG_X86 or?
=
-Bruce
=A0
Thanks,
Ian.


--0016e64cad1e18f908048a7029d6-- --===============0815932873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0815932873==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 6 Jul 2010 12:57:39 +0100 Message-ID: <19507.6707.47260.44850@mariner.uk.xensource.com> References: <19502.6544.743563.733900@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: Keir, "xen-devel@lists.xensource.com" , Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 6 Jul 2010 06:37:28 -0700 Message-ID: References: <19502.6544.743563.733900@mariner.uk.xensource.com> <19507.6707.47260.44850@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1974089014==" Return-path: In-Reply-To: <19507.6707.47260.44850@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============1974089014== Content-Type: multipart/alternative; boundary=0016e646982c8d5bd7048ab82796 --0016e646982c8d5bd7048ab82796 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 6, 2010 at 4:57 AM, Ian Jackson 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. > --0016e646982c8d5bd7048ab82796 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 i= n xen-4.0-testing.hg and debugger =A0documentation."):
> Here is a patch to enable gdbsx by default.
Thanks. =A0Is it against 4.0-testing as it seems to be ? =A0

Yes, it is.
=A0
I think we
probably want this against xen-unstable, against which your patch
doesn't apply.

OK, I'll pull do= wn an unstable tree and resubmit.

Thanks for the h= elp.

-Bruce
=A0

> I suppose it would be cleaner to eliminate the debugger dir as gdbsx i= s the
> only one under there that's used and that would enable the tools/R= ules.mk
> templates to cover the
> =A0 =A0 subdir-clean-gdbsx:
> =A0 =A0 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
> =A0 =A0 SUBDIRS-y +=3D 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.

--0016e646982c8d5bd7048ab82796-- --===============1974089014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1974089014==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 6 Jul 2010 16:40:56 -0700 Message-ID: References: <19502.6544.743563.733900@mariner.uk.xensource.com> <19507.6707.47260.44850@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1763656779==" Return-path: In-Reply-To: <19507.6707.47260.44850@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============1763656779== Content-Type: multipart/alternative; boundary=001636d340b1ae9074048ac09527 --001636d340b1ae9074048ac09527 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 6, 2010 at 4:57 AM, Ian Jackson 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. > --001636d340b1ae9074048ac09527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 i= n xen-4.0-testing.hg and debugger =A0documentation."):
> Here is a patch to enable gdbsx by default.
Thanks. =A0Is it against 4.0-testing as it seems to be ? =A0I think w= e
probably want this against xen-unstable, against which your patch
doesn't apply.

Ian, here's an u= nstable patch:

diff -Naur xen-unstable.hg-201= 0-07-06/tools/Makefile xen-unstable.hg/tools/Makefile
--- xen-uns= table.hg-2010-07-06/tools/Makefile =A0 2010-07-06 14:40:54.000000000 -0700<= /div>
+++ xen-unstable.hg/tools/Makefile =A0 =A0 =A02010-07-06 16:15:15.0000= 00000 -0700
@@ -35,6 +35,7 @@
=A0SUBDIRS-y +=3D libxl
=A0SUBDIRS-y +=3D remus
=A0SUBDIRS-$(CONFIG_X86) +=3D xe= npaging
+SUBDIRS-y +=3D debugger/gdbsx
=A0
=A0# These don't= cross-compile
=A0ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -114,3 +115,9 @@
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$(= buildmakevars2shellvars); \
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$(MAKE) -C ioemu-dir clean; \
<= div>=A0=A0 =A0 =A0 =A0fi
+
+subdir-clean-debugger/gdbsx= :
+ =A0 =A0 =A0 $(MAKE) -C debugger/gdbsx clean
+
=
+subdir-install-debugger/gdbsx:
+ =A0 =A0 =A0 $(MAKE) -C debugger/gdbsx install

-------------cut----------------
=A0
Thanks

-Bruce


> I suppose it would be cleaner to eliminate the debugger dir as gdbsx i= s the
> only one under there that's used and that would enable the tools/R= ules.mk
> templates to cover the
> =A0 =A0 subdir-clean-gdbsx:
> =A0 =A0 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
> =A0 =A0 SUBDIRS-y +=3D 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.

--001636d340b1ae9074048ac09527-- --===============1763656779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1763656779==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Thu, 8 Jul 2010 16:51:07 +0100 Message-ID: <19509.62443.169165.677514@mariner.uk.xensource.com> References: <19502.6544.743563.733900@mariner.uk.xensource.com> <19507.6707.47260.44850@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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 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. -- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 13 Jul 2010 22:29:48 -0700 Message-ID: References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2127101648==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============2127101648== Content-Type: multipart/alternative; boundary=002215048e5739979f048b5246b5 --002215048e5739979f048b5246b5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge wrote: > On Thu, Jul 1, 2010 at 1: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. >> >> 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 }, 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 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 >> >> > --002215048e5739979f048b5246b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge <bruce.edge@gmail.c= om> 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=3Dy =A0is 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. =A0tools/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 mod= ule debugging.

The docs for using gdbsx state:

=A0=A0 - Additionally, to debug loadable kernel mo= dules, please do following:
=A0=A0 =A0 =A0(gdb) p init_mm.pgd[3]<= /div>
=A0=A0 =A0 =A0$1 =3D {pgd =3D 0x1b874f027}
=A0=A0 =A0 = =A0(gdb) monitor pgd3 0x1b874f027 =A0(Make sure value is in HEX)
=A0=A0 =A0 =A0pgd3val set to: 0x1b874f027

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

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

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 fie= ld are we after with this command?

Here's the full struct:

(gdb) p init_mm
$2 =3D {mmap =3D 0x0, mm_rb =3D {rb_node =3D 0= x0}, mmap_cache =3D 0x0, get_unmapped_area =3D 0, unmap_area =3D 0, mmap_ba= se =3D 0, task_size =3D 0, cached_hole_size =3D 0, free_area_cache =3D 0,
=A0=A0pgd =3D 0xffffffff81001000, mm_users =3D {counter =3D 2}, mm_cou= nt =3D {counter =3D 15}, map_count =3D 0, mmap_sem =3D {count =3D 0, wait_l= ock =3D {raw_lock =3D {{slock =3D 0, tickets =3D {head =3D 0 '\0',<= /div>
=A0=A0 =A0 =A0 =A0 =A0 =A0tail =3D 0 '\0'}}, waiting =3D = 0 '\0'}}, wait_list =3D {next =3D 0xffffffff81952ed0, prev =3D 0xff= ffffff81952ed0}}, page_table_lock =3D {raw_lock =3D {{slock =3D 4369, ticke= ts =3D {
=A0=A0 =A0 =A0 =A0 =A0head =3D 17 '\021', tail =3D 17 '\02= 1'}}, waiting =3D 0 '\0'}}, mmlist =3D {next =3D 0xffffffff8195= 2ee8, prev =3D 0xffffffff81952ee8}, _file_rss =3D {counter =3D 0}, _anon_rs= s =3D {counter =3D 0},
=A0=A0hiwater_rss =3D 0, hiwater_vm =3D 0, total_vm =3D 0, locked_vm = =3D 0, shared_vm =3D 0, exec_vm =3D 0, stack_vm =3D 0, reserved_vm =3D 0, d= ef_flags =3D 0, nr_ptes =3D 0, start_code =3D 18446744071578845184,
=A0=A0end_code =3D 18446744071585415526, start_data =3D 0, end_data =3D = 18446744071589170120, start_brk =3D 0, brk =3D 18446744071591583744, start_= stack =3D 0, arg_start =3D 0, arg_end =3D 0, env_start =3D 0,
=A0=A0env_end =3D 0, saved_auxv =3D {0 <repeats 44 times>}, binf= mt =3D 0x0, cpu_vm_mask =3D {bits =3D {18446744073709551598}}, context =3D = {ldt =3D 0x0, size =3D 0, lock =3D {count =3D {counter =3D 0}, wait_lock = =3D {
=A0=A0 =A0 =A0 =A0raw_lock =3D {{slock =3D 0, tickets =3D {= head =3D 0 '\0', tail =3D 0 '\0'}}, waiting =3D 0 '\0&#= 39;}}, wait_list =3D {next =3D 0x0, prev =3D 0x0}, owner =3D 0x0}, vdso =3D= 0x0, has_foreign_mappings =3D 0},
=A0=A0faultstamp =3D 0, token_priority =3D 0, last_interval =3D 0, fla= gs =3D 0, core_state =3D 0x0, ioctx_lock =3D {raw_lock =3D {{slock =3D 0, t= ickets =3D {head =3D 0 '\0', tail =3D 0 '\0'}}, waiting =3D= 0 '\0'}},
=A0=A0ioctx_list =3D {first =3D 0x0}, owner =3D 0xffffffff81940600, ex= e_file =3D 0x0, num_exe_file_vmas =3D 0, mmu_notifier_mm =3D 0x0}

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


Thanks

-Bruce
= =A0
Mukesh,=A0

Thanks for th= e update, this clarifies a lot and eliminates a all of the residual chaff f= rom old posting, versions, etc.

-Bruce
=A0
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 mechanis= m
> > 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 a= s 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 hea= ds)
> > 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' refer= s to
> > unknown node .hgtags@809b20f066fb, line 41: tag '4.0.0-rc3= 9; 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-debug= ging
> > refers to magically generated Oracle images with no information o= n
> > 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=3Dy gdbsx=3Dy && make dist
> >
> > Thanks
> >
> > -Bruce
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel



--002215048e5739979f048b5246b5-- --===============2127101648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2127101648==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 13 Jul 2010 22:37:08 -0700 Message-ID: References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0737522540==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============0737522540== Content-Type: multipart/alternative; boundary=001485e98b22749de6048b5260ce --001485e98b22749de6048b5260ce Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 10:29 PM, Bruce Edge wrote: > On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge wrote: > >> On Thu, Jul 1, 2010 at 1: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. >>> >>> 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 }, 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 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 >>> >>> >> > --001485e98b22749de6048b5260ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 Rath= or <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=3Dy =A0is 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. =A0tools/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 regardi= ng module debugging.

The docs for using gdbsx stat= e:

=A0=A0 - Additionally, to debug loadable kernel mo= dules, please do following:
=A0=A0 =A0 =A0(gdb) p init_mm.pgd[3]<= /div>
=A0=A0 =A0 =A0$1 =3D {pgd =3D 0x1b874f027}
=A0=A0 =A0 = =A0(gdb) monitor pgd3 0x1b874f027 =A0(Make sure value is in HEX)
=A0=A0 =A0 =A0pgd3val set to: 0x1b874f027

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

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

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 fie= ld are we after with this command?

Here's the full struct:

(gdb) p init_mm
$2 =3D {mmap =3D 0x0, mm_rb =3D {rb_node =3D 0= x0}, mmap_cache =3D 0x0, get_unmapped_area =3D 0, unmap_area =3D 0, mmap_ba= se =3D 0, task_size =3D 0, cached_hole_size =3D 0, free_area_cache =3D 0,
=A0=A0pgd =3D 0xffffffff81001000, mm_users =3D {counter =3D 2}, mm_cou= nt =3D {counter =3D 15}, map_count =3D 0, mmap_sem =3D {count =3D 0, wait_l= ock =3D {raw_lock =3D {{slock =3D 0, tickets =3D {head =3D 0 '\0',<= /div>
=A0=A0 =A0 =A0 =A0 =A0 =A0tail =3D 0 '\0'}}, waiting =3D = 0 '\0'}}, wait_list =3D {next =3D 0xffffffff81952ed0, prev =3D 0xff= ffffff81952ed0}}, page_table_lock =3D {raw_lock =3D {{slock =3D 4369, ticke= ts =3D {
=A0=A0 =A0 =A0 =A0 =A0head =3D 17 '\021', tail =3D 17 '\02= 1'}}, waiting =3D 0 '\0'}}, mmlist =3D {next =3D 0xffffffff8195= 2ee8, prev =3D 0xffffffff81952ee8}, _file_rss =3D {counter =3D 0}, _anon_rs= s =3D {counter =3D 0},
=A0=A0hiwater_rss =3D 0, hiwater_vm =3D 0, total_vm =3D 0, locked_vm = =3D 0, shared_vm =3D 0, exec_vm =3D 0, stack_vm =3D 0, reserved_vm =3D 0, d= ef_flags =3D 0, nr_ptes =3D 0, start_code =3D 18446744071578845184,
=A0=A0end_code =3D 18446744071585415526, start_data =3D 0, end_data =3D = 18446744071589170120, start_brk =3D 0, brk =3D 18446744071591583744, start_= stack =3D 0, arg_start =3D 0, arg_end =3D 0, env_start =3D 0,
=A0=A0env_end =3D 0, saved_auxv =3D {0 <repeats 44 times>}, binf= mt =3D 0x0, cpu_vm_mask =3D {bits =3D {18446744073709551598}}, context =3D = {ldt =3D 0x0, size =3D 0, lock =3D {count =3D {counter =3D 0}, wait_lock = =3D {
=A0=A0 =A0 =A0 =A0raw_lock =3D {{slock =3D 0, tickets =3D {= head =3D 0 '\0', tail =3D 0 '\0'}}, waiting =3D 0 '\0&#= 39;}}, wait_list =3D {next =3D 0x0, prev =3D 0x0}, owner =3D 0x0}, vdso =3D= 0x0, has_foreign_mappings =3D 0},
=A0=A0faultstamp =3D 0, token_priority =3D 0, last_interval =3D 0, fla= gs =3D 0, core_state =3D 0x0, ioctx_lock =3D {raw_lock =3D {{slock =3D 0, t= ickets =3D {head =3D 0 '\0', tail =3D 0 '\0'}}, waiting =3D= 0 '\0'}},
=A0=A0ioctx_list =3D {first =3D 0x0}, owner =3D 0xffffffff81940600, ex= e_file =3D 0x0, num_exe_file_vmas =3D 0, mmu_notifier_mm =3D 0x0}

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


Thanks

-Bruce
=A0
<= /div>



=
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 = =A0 =A0 =A0 PID =A0 =A0 =A0Command
/build/buildd/gdb-6.8/gdb/printcmd.c:2261: internal-error: printf_comm= and: Assertion `*p =3D=3D 'p' && *(p + 1) =3D=3D '\0= 9;' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging sessi= on? (y or n) [answered Y; input not from terminal]
/build/buildd/= gdb-6.8/gdb/printcmd.c:2261: internal-error: printf_command: Assertion `*p = =3D=3D 'p' && *(p + 1) =3D=3D '\0'' failed.
A problem internal to GDB has been detected,
further debuggi= ng may prove unreliable.
Create a core file of GDB? (y or n) [ans= wered Y; input not from terminal]
zsh: abort =A0 =A0 =A0gdb ./vml= inux

-Bruce

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Mukesh,=A0

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

-Bruce
=A0
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 mechanis= m
> > 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 a= s 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 hea= ds)
> > 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' refer= s to
> > unknown node .hgtags@809b20f066fb, line 41: tag '4.0.0-rc3= 9; 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-debug= ging
> > refers to magically generated Oracle images with no information o= n
> > 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=3Dy gdbsx=3Dy && make dist
> >
> > Thanks
> >
> > -Bruce
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel




--001485e98b22749de6048b5260ce-- --===============0737522540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0737522540==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Wed, 14 Jul 2010 07:29:46 -0700 Message-ID: References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> <4C2D0E9A.4010100@goop.org> <20100701150802.54bad0ef@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001636d34ceb49b482048b59d107 Return-path: In-Reply-To: <20100701150802.54bad0ef@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --001636d34ceb49b482048b59d107 Content-Type: multipart/alternative; boundary=001636d34ceb49b47b048b59d105 --001636d34ceb49b47b048b59d105 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor wrote: > On Thu, 01 Jul 2010 23:54:34 +0200 > Jeremy Fitzhardinge 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 > > --001636d34ceb49b47b048b59d105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor <mukesh.rath= or@oracle.com> wrote:
On Thu, 01 Jul 2010 23:54:34 +0200
Jeremy Fitzhardinge <jeremy@goop.org<= /a>> wrote:

> On 07/01/2010 10:13 PM, Mukesh Rathor wrote:
> > Thanks for CC Konrad, I'm gazillions postings behind in catch= ing 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=3Dy =A0is 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 wi= th
> multi-vcpu guests by treating the vcpus as threads within gdb. =A0Is > there some other way to look at all the threads' contexts from wit= hin
> gdb?
>
> =A0 =A0 J

Hmm... working for me. Can you please run gdbsx with -d and tar
and send output to me?



=A0
BTW, what xen and guest versions?


Thanks for looking into this.

= -Bruce


thanks,
M


--001636d34ceb49b47b048b59d105-- --001636d34ceb49b482048b59d107 Content-Type: application/x-gzip; name="screenlog.23.gz" Content-Disposition: attachment; filename="screenlog.23.gz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbm9ok490 H4sICP7IPUwAA3NjcmVlbmxvZy4yMwDtW9tuGzcQfTfgf9gPiAPelpftQ1EEBgq0aIqmD34zSC4p C40kW5ID5+9LyUm0UhKuZki5DmoatrXSLHfPnpkh56JJ71YPzYVteCNFY9JoLvrz87OHyfV0Pl13 l7uXV13sO749tuu19TfdZdcvZtPtm9f+Jvh/rm8+3nZXl3+8+eXPd91DmF/w1+TiQcvrNPfwkLPb 5ubDbHB8cLj/cTr7/Oz36Wod5tP5pFnMm9vFcr292/Ozv8JssQ5NH9z9ZLL5OC4Xs+ZmsVo3lLev qTCvVfrHxfnZ7XLhw2p1vdyekv7d3YdVwtjdvbu/3UwZ+sbfLz/42/uOfFf8qjtC6LL7+aip/ibt +mYZbN+Rn46a9ld/QY+a+e1vR81396Ye5Lu3Ma7CelVvxslQKineMkw2UulxXXWPbzduup6nc7uk JEufvSI5HO3BcfxKAja005oon17omIbRTg2Pg+bK9JrGT2N8QimGR147M5xv9HRxcCgJ52J3fcop G37OediTZ27/uHS8MD4+4f+Q8bt3H2du8b47xiMc6Tb+BtzA0Z5ytnmCie7EhyZOU/JKf6Wrtr+e hdlGjT/Y7lC+WS/cfeyooJYw0rwP807vn3fVpava6Xyj5PdRd+ThM3OattRxEzMwTHS8pTuyMaCI hoEiGgtq8GB0BhQ9sDAMKAZkihUyJXlUVOZAyagkL2OKApmiFZhqc0y15UypAGMqyWNA0dyKQREe 7BAFjJokX06NylGjKlATgdTEEiPqM2Biv7+WosAAGYoohiA7E4wLkEC/Jiv4NWVzembL/VoL9Gtt BeOROeORFVYgBWRKFTJFDFMy5EAFpogpY0oCmZIVmDI5pkwFpiyQKVtsU73sWQZUz3pZalMGyJSp wJTPMeUrMMWBoDga1CNTmhmp2pz3a43UDMPU8ALHgBrKY0DxwAlPD19xRWQUuaBCxLRXTYIpVvTp pIBhSgBtSqBt6sscZkz9TLH6AUFxFKhTbyF6IIq+dGESPOrcFkJbHokoc3ce6Bl8ubszJKdvpIK+ OSBT7kcwIg8E5Z+lETmgvrmilSjGNiZXnAflebuTx1BjgOktU5reIkJQnYv7dC9ooWcwwPSWqZDe MmNJk2IjAkbmGh+ZP6FnAOZQNC6HcmrPAMxnaVw+64k9AwF6BoIClXCQ0UQdL6LHABMopjSBknwc Ezy32+aClfo4YALFVEigmLEESqk7MMAEiilNoEge2/D9joGrLojYFoblBphAMRUSKMblmHIVmAJu 6QxuSzdkyts2F5a3rbc4pnYXSMEeHQc1lP8GKDoOKpf2xrEBVDFcKJQzlMOSNAYFcINt8BvsL3PY MUOxhYZigYZiSw2lpY75HFNeOFZYP7ZApmwNpsb2osVMAZMktjRJwgWhQeUWH0UoL9smWKBnsBWS JE7kmBLaudLFxwAXH/Mc68fGAt2dxTltksvDEbvvuFFsAHHgyg4njuFcC9OpJP/8+3ySJcJAiQrW P5YIKbV+BwznXI16+Kn7fBwwnHMVwjk3VmUtZgrYkeVwHVkn9tOOAalhFagZ25YWUwOsazlcXeuT QZy4z8cBa8QOVyM+9QoE7Elw5T0Jp+/zccDNgavQk5AigQwoW8F4gEU6hy/SPTL1FH0+Drgddbjt 6P4cfY6pvgJTwMy8K8vMP02fT3pqMFB9OVN+rPDtS5lSQFCquM9H2hGbkrasz2dzAUifz0YeA4oR 6SVVTLbpnluZSylI9SiUhKn0DLBO7W5SSRgoJTGgpFFC8nSnIu2uk3fLrVMkwYlJsJU8/TUoUECm FIqpdHdetenRy8RZkLnwT8bk1ImUidg2nSQwoDSQKY1jKop0p9wKI3oRRuqSIiQhwy1LryTKUWig S9fldXA/1nZf7v2AoHCFr5PngjywncQXt5NQbXWOHK21JWVZFA9sJ/EV2kk8z4HiFTQO+N0Ih/tu xMt6+7Levqy3P/R6C+w7cxX6zk6/3mqg99PPs/bigT33Ht9z/6i1Kb7lNBffUtbzwvjWA9N5Hv+V j90cY61NpRrngblwj/928tOZkQemxj0uNX56MwJuv31535m3LNfNxCp0MxFgN9M3Gzj/g24mD0wF eVwqiBFCc2vntnLEoHq1nfWVyd/+Vugb92zGu2U5S7+PP5Tl2nyY4PSL6PYkDBXAYNvjg+3hyGrU /oAZxucxRtBXV0FwJffGCFfyYKC4ApoNbk9z4mqrBxaMfIWCUT8WbPeF62S6wDEaN5THaNz+HGMl 5D1QOO8ArFh6XMWS8ZzOcUpYqc4BS18eX/ryZnOPLsXPIrf2CMKkUxtRb2A6N7zAMTo3lMfoHKQo jiMHWGz1uGIrtrj/LxduaNBZUQAA --001636d34ceb49b482048b59d107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --001636d34ceb49b482048b59d107-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Wed, 14 Jul 2010 14:10:27 -0700 Message-ID: <20100714141027.30707b98@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Tue, 13 Jul 2010 22:29:48 -0700 Bruce Edge 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Wed, 14 Jul 2010 15:35:09 -0700 Message-ID: <20100714153509.37f9c772@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Wed, 14 Jul 2010 16:17:16 -0700 Message-ID: <20100714161716.097d679a@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> <4C2D0E9A.4010100@goop.org> <20100701150802.54bad0ef@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Wed, 14 Jul 2010 07:29:46 -0700 Bruce Edge wrote: > On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor > wrote: > > > On Thu, 01 Jul 2010 23:54:34 +0200 > > Jeremy Fitzhardinge 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Wed, 14 Jul 2010 19:18:37 -0700 Message-ID: <20100714191837.7a5a2928@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> <4C2D0E9A.4010100@goop.org> <20100701150802.54bad0ef@mantra.us.oracle.com> <20100714161716.097d679a@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100714161716.097d679a@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Bruce Edge , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Wed, 14 Jul 2010 16:17:16 -0700 Mukesh Rathor wrote: > On Wed, 14 Jul 2010 07:29:46 -0700 > Bruce Edge wrote: > > > On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor > > wrote: > > > > > On Thu, 01 Jul 2010 23:54:34 +0200 > > > Jeremy Fitzhardinge 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 28 Sep 2010 09:55:59 -0700 Message-ID: References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> <20100714141027.30707b98@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100714141027.30707b98@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Wed, Jul 14, 2010 at 2:10 PM, Mukesh Rathor w= rote: > > > On Tue, 13 Jul 2010 22:29:48 -0700 > Bruce Edge wrote: >> The docs for using gdbsx state: >> >> =A0 =A0- Additionally, to debug loadable kernel modules, please do >> following: (gdb) p init_mm.pgd[3] >> =A0 =A0 =A0 $1 =3D {pgd =3D 0x1b874f027} >> =A0 =A0 =A0 (gdb) monitor pgd3 0x1b874f027 =A0(Make sure value is in HEX= ) >> =A0 =A0 =A0 pgd3val set to: 0x1b874f027 >> >> When I try to use this to access a module, I get: >> >> (gdb) p init_mm.pgd[3] >> $10 =3D {pgd =3D 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation. Date: Tue, 28 Sep 2010 18:58:37 -0700 Message-ID: <20100928185837.315f43f8@mantra.us.oracle.com> References: <20100701145331.GC31947@phenom.dumpdata.com> <20100701131336.5409f873@mantra.us.oracle.com> <20100714141027.30707b98@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Bruce Edge Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Tue, 28 Sep 2010 09:55:59 -0700 Bruce Edge wrote: > On Wed, Jul 14, 2010 at 2:10 PM, Mukesh Rathor > wrote: > > > > > > On Tue, 13 Jul 2010 22:29:48 -0700 > > Bruce Edge wrote: > >> The docs for using gdbsx state: > >> > >> =C2=A0 =C2=A0- Additionally, to debug loadable kernel modules, please = do > >> following: (gdb) p init_mm.pgd[3] > >> =C2=A0 =C2=A0 =C2=A0 $1 =3D {pgd =3D 0x1b874f027} > >> =C2=A0 =C2=A0 =C2=A0 (gdb) monitor pgd3 0x1b874f027 =C2=A0(Make sure v= alue is in HEX) > >> =C2=A0 =C2=A0 =C2=A0 pgd3val set to: 0x1b874f027 > >> > >> When I try to use this to access a module, I get: > >> > >> (gdb) p init_mm.pgd[3] > >> $10 =3D {pgd =3D 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 > > > > >=20 > 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.=20 > Are there any tutorials illustrating the use of gdbsx with a custom > kernel module? This would be most helpful. Nop, not at present. Mukesh