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

[Bruce Edge <bruce.edge@xxxxxxxxx>]

On Thu, Jul 1, 2010 at 11:11 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:

On 02/07/2010 00:51, "Bruce Edge" <bruce.edge@xxxxxxxxx> wrote:

> Is there any reason to not build gdbsx by default?
>
> IOW does it affect performance?

There's no reason not to build it always. We could get rid of the build-time
option.

That would simplify the downstream packaging. They wouldn't need to provide an additional mechanism/hook/option to get gdbsx installed. 

The current debian packaging patch is a widely used "get this onto my box" aid, and it has no facility for tweaking the build options.

-Bruce

 

 -- Keir

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

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