State of gdbsx in xen-4.0-testing.hg and debugger documentation.

State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2606 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Konrad Rzeszutek Wilk]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

Thanks for CC Konrad, I'm gazillions postings behind in catching up
xen-devel.

Bruce, you don't need to use the ext repo anymore as gdbsx is now
merged mainline. I should update the blog post.

To build a debug enabled xen image: make gdbsx=y  is all you need
to do. After booting with gdbsx enabled xen, you can run gdbsx in
dom0. See tools/debugger/gdbsx/README. 

Note, you don't need to do anything in tools/debugger/gdb and/or
gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.

Perhaps, we should just remove tools/debugger/gdb if it's not being
maintained and no one is using it.

thanks,
Mukesh



On Thu, 1 Jul 2010 10:53:31 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 3155 bytes --]

On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor <mukesh.rathor@oracle.com>wrote:

> Thanks for CC Konrad, I'm gazillions postings behind in catching up
> xen-devel.
>
> Bruce, you don't need to use the ext repo anymore as gdbsx is now
> merged mainline. I should update the blog post.
>
> To build a debug enabled xen image: make gdbsx=y  is all you need
> to do. After booting with gdbsx enabled xen, you can run gdbsx in
> dom0. See tools/debugger/gdbsx/README.
>
> Note, you don't need to do anything in tools/debugger/gdb and/or
> gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.
>
> Perhaps, we should just remove tools/debugger/gdb if it's not being
> maintained and no one is using it.
>
>
Mukesh,

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

-Bruce


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

[-- Attachment #1.2: Type: text/html, Size: 4812 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 5867 bytes --]

On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge <bruce.edge@gmail.com> wrote:

> On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor <mukesh.rathor@oracle.com>wrote:
>
>> Thanks for CC Konrad, I'm gazillions postings behind in catching up
>> xen-devel.
>>
>> Bruce, you don't need to use the ext repo anymore as gdbsx is now
>> merged mainline. I should update the blog post.
>>
>> To build a debug enabled xen image: make gdbsx=y  is all you need
>> to do. After booting with gdbsx enabled xen, you can run gdbsx in
>> dom0. See tools/debugger/gdbsx/README.
>>
>> Note, you don't need to do anything in tools/debugger/gdb and/or
>> gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.
>>
>> Perhaps, we should just remove tools/debugger/gdb if it's not being
>> maintained and no one is using it.
>>
>>
>
I think there's something wrong with the docs for gdbsx regarding module
debugging.

The docs for using gdbsx state:

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

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

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

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

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

Here's the full struct:

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

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


Thanks

-Bruce


> Mukesh,
>

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

[-- Attachment #1.2: Type: text/html, Size: 8767 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 6965 bytes --]

On Tue, Jul 13, 2010 at 10:29 PM, Bruce Edge <bruce.edge@gmail.com> wrote:

> On Thu, Jul 1, 2010 at 1:47 PM, Bruce Edge <bruce.edge@gmail.com> wrote:
>
>> On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor <mukesh.rathor@oracle.com>wrote:
>>
>>> Thanks for CC Konrad, I'm gazillions postings behind in catching up
>>> xen-devel.
>>>
>>> Bruce, you don't need to use the ext repo anymore as gdbsx is now
>>> merged mainline. I should update the blog post.
>>>
>>> To build a debug enabled xen image: make gdbsx=y  is all you need
>>> to do. After booting with gdbsx enabled xen, you can run gdbsx in
>>> dom0. See tools/debugger/gdbsx/README.
>>>
>>> Note, you don't need to do anything in tools/debugger/gdb and/or
>>> gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.
>>>
>>> Perhaps, we should just remove tools/debugger/gdb if it's not being
>>> maintained and no one is using it.
>>>
>>>
>>
> I think there's something wrong with the docs for gdbsx regarding module
> debugging.
>
> The docs for using gdbsx state:
>
>    - Additionally, to debug loadable kernel modules, please do following:
>       (gdb) p init_mm.pgd[3]
>       $1 = {pgd = 0x1b874f027}
>       (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
>       pgd3val set to: 0x1b874f027
>
> When I try to use this to access a module, I get:
>
> (gdb) p init_mm.pgd[3]
> $10 = {pgd = 0}
> (gdb)
>
> I assume that the value of pgd should not be 0 as the makes the next
> command it the docs meaningless.
>
> Is it possible that the field [3] offset has changed?
> What field are we after with this command?
>
> Here's the full struct:
>
> (gdb) p init_mm
> $2 = {mmap = 0x0, mm_rb = {rb_node = 0x0}, mmap_cache = 0x0,
> get_unmapped_area = 0, unmap_area = 0, mmap_base = 0, task_size = 0,
> cached_hole_size = 0, free_area_cache = 0,
>   pgd = 0xffffffff81001000, mm_users = {counter = 2}, mm_count = {counter =
> 15}, map_count = 0, mmap_sem = {count = 0, wait_lock = {raw_lock = {{slock =
> 0, tickets = {head = 0 '\0',
>             tail = 0 '\0'}}, waiting = 0 '\0'}}, wait_list = {next =
> 0xffffffff81952ed0, prev = 0xffffffff81952ed0}}, page_table_lock = {raw_lock
> = {{slock = 4369, tickets = {
>           head = 17 '\021', tail = 17 '\021'}}, waiting = 0 '\0'}}, mmlist
> = {next = 0xffffffff81952ee8, prev = 0xffffffff81952ee8}, _file_rss =
> {counter = 0}, _anon_rss = {counter = 0},
>   hiwater_rss = 0, hiwater_vm = 0, total_vm = 0, locked_vm = 0, shared_vm =
> 0, exec_vm = 0, stack_vm = 0, reserved_vm = 0, def_flags = 0, nr_ptes = 0,
> start_code = 18446744071578845184,
>   end_code = 18446744071585415526, start_data = 0, end_data =
> 18446744071589170120, start_brk = 0, brk = 18446744071591583744, start_stack
> = 0, arg_start = 0, arg_end = 0, env_start = 0,
>   env_end = 0, saved_auxv = {0 <repeats 44 times>}, binfmt = 0x0,
> cpu_vm_mask = {bits = {18446744073709551598}}, context = {ldt = 0x0, size =
> 0, lock = {count = {counter = 0}, wait_lock = {
>         raw_lock = {{slock = 0, tickets = {head = 0 '\0', tail = 0 '\0'}},
> waiting = 0 '\0'}}, wait_list = {next = 0x0, prev = 0x0}, owner = 0x0}, vdso
> = 0x0, has_foreign_mappings = 0},
>   faultstamp = 0, token_priority = 0, last_interval = 0, flags = 0,
> core_state = 0x0, ioctx_lock = {raw_lock = {{slock = 0, tickets = {head = 0
> '\0', tail = 0 '\0'}}, waiting = 0 '\0'}},
>   ioctx_list = {first = 0x0}, owner = 0xffffffff81940600, exe_file = 0x0,
> num_exe_file_vmas = 0, mmu_notifier_mm = 0x0}
>
> This is with xen-unstable sync'd a few hours ago.
>
>
> Thanks
>
> -Bruce
>
>



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

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

-Bruce



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

[-- Attachment #1.2: Type: text/html, Size: 10480 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

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

Bruce,

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

Thanks,
Mukesh

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

On Wed, Jul 14, 2010 at 2:10 PM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>
>
> On Tue, 13 Jul 2010 22:29:48 -0700
> Bruce Edge <bruce.edge@gmail.com> wrote:
>> The docs for using gdbsx state:
>>
>>    - Additionally, to debug loadable kernel modules, please do
>> following: (gdb) p init_mm.pgd[3]
>>       $1 = {pgd = 0x1b874f027}
>>       (gdb) monitor pgd3 0x1b874f027  (Make sure value is in HEX)
>>       pgd3val set to: 0x1b874f027
>>
>> When I try to use this to access a module, I get:
>>
>> (gdb) p init_mm.pgd[3]
>> $10 = {pgd = 0}
>> (gdb)
>>
>> I assume that the value of pgd should not be 0 as the makes the next
>> command it the docs meaningless.
>>
>> Is it possible that the field [3] offset has changed?
>> What field are we after with this command?
>>
>
> Bruce,
>
> This for 32bit domU kernel only. I guess the README is not updated in
> all trees.. I'll submit patch to do this.
>
> Thanks,
> Mukesh
>
>

Mukesh,
I'm getting back to working on the debugger and have not been able to
use it with any modules. How does one set breakpoints for modules that
are not loaded?
This may be a lack of experience with kernel/gdb context, but how does
one go about setting a breakpoint in a module's init code?
Is there any method to use to put in a symbolic function name as a
breakpoint for a module that is not yet loaded?

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

Thanks

-Bruce

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

On Tue, 28 Sep 2010 09:55:59 -0700
Bruce Edge <bruce.edge@gmail.com> wrote:

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

You cannot.

> This may be a lack of experience with kernel/gdb context, but how does
> one go about setting a breakpoint in a module's init code?
> Is there any method to use to put in a symbolic function name as a
> breakpoint for a module that is not yet loaded?

Set breakpoint in kernel load module function, and step from there. 

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

Nop, not at present.

Mukesh

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Keir Fraser]

On 01/07/2010 21:13, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> Note, you don't need to do anything in tools/debugger/gdb and/or
> gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.
> 
> Perhaps, we should just remove tools/debugger/gdb if it's not being
> maintained and no one is using it.

I think that would be a good idea. It's a decision for Ian or Stefano
(cc'ed) though.

 -- Keir

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Stefano Stabellini]

On Thu, 1 Jul 2010, Keir Fraser wrote:
> On 01/07/2010 21:13, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
> 
> > Note, you don't need to do anything in tools/debugger/gdb and/or
> > gdbbuild.  tools/debugger/gdb (gdbbuild) is unlreated to gdbsx.
> > 
> > Perhaps, we should just remove tools/debugger/gdb if it's not being
> > maintained and no one is using it.
> 
> I think that would be a good idea. It's a decision for Ian or Stefano
> (cc'ed) though.
> 
 
Definitely a good idea

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Ian Jackson]

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.

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Jeremy Fitzhardinge]

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

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

    J

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

On Thu, 01 Jul 2010 23:54:34 +0200
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> On 07/01/2010 10:13 PM, Mukesh Rathor wrote:
> > Thanks for CC Konrad, I'm gazillions postings behind in catching up
> > xen-devel.
> >
> > Bruce, you don't need to use the ext repo anymore as gdbsx is now
> > merged mainline. I should update the blog post.
> >
> > To build a debug enabled xen image: make gdbsx=y  is all you need
> > to do. After booting with gdbsx enabled xen, you can run gdbsx in
> > dom0. See tools/debugger/gdbsx/README. 
> >   
> 
> I noticed when I tried gdbsx today that it doesn't seem to deal with
> multi-vcpu guests by treating the vcpus as threads within gdb.  Is
> there some other way to look at all the threads' contexts from within
> gdb?
> 
>     J

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

BTW, what xen and guest versions?

thanks,
M

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 1367 bytes --]

On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor <mukesh.rathor@oracle.com>wrote:

> On Thu, 01 Jul 2010 23:54:34 +0200
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> > On 07/01/2010 10:13 PM, Mukesh Rathor wrote:
> > > Thanks for CC Konrad, I'm gazillions postings behind in catching up
> > > xen-devel.
> > >
> > > Bruce, you don't need to use the ext repo anymore as gdbsx is now
> > > merged mainline. I should update the blog post.
> > >
> > > To build a debug enabled xen image: make gdbsx=y  is all you need
> > > to do. After booting with gdbsx enabled xen, you can run gdbsx in
> > > dom0. See tools/debugger/gdbsx/README.
> > >
> >
> > I noticed when I tried gdbsx today that it doesn't seem to deal with
> > multi-vcpu guests by treating the vcpus as threads within gdb.  Is
> > there some other way to look at all the threads' contexts from within
> > gdb?
> >
> >     J
>
> Hmm... working for me. Can you please run gdbsx with -d and tar
> and send output to me?
>
> Mukesh,

Here's the output from gdbsx -d when trying to view CPUs as thread.



> BTW, what xen and guest versions?
>

xen 4.1 unstable sync'd last night
dom0:  Linux kaan-22 2.6.32.16 #1 SMP Mon Jul 12 14:00:17 UTC 2010 x86_64
GNU/Linux
domU: Same: Linux kaan-22 2.6.32.16 #1 SMP Mon Jul 12 14:00:17 UTC 2010
x86_64 GNU/Linux

Thanks for looking into this.

-Bruce


> thanks,
> M
>
>

[-- Attachment #1.2: Type: text/html, Size: 2292 bytes --]

[-- Attachment #2: screenlog.23.gz --]
[-- Type: application/x-gzip, Size: 1788 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

On Wed, 14 Jul 2010 07:29:46 -0700
Bruce Edge <bruce.edge@gmail.com> wrote:

> On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor
> <mukesh.rathor@oracle.com>wrote:
> 
> > On Thu, 01 Jul 2010 23:54:34 +0200
> > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >
> > > I noticed when I tried gdbsx today that it doesn't seem to deal
> > > with multi-vcpu guests by treating the vcpus as threads within
> > > gdb.  Is there some other way to look at all the threads'
> > > contexts from within gdb?
> > >
> > Hmm... working for me. Can you please run gdbsx with -d and tar
> > and send output to me?
> >
> > Mukesh,
> 
> Here's the output from gdbsx -d when trying to view CPUs as thread.


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

thanks
Mukesh

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Mukesh Rathor]

On Wed, 14 Jul 2010 16:17:16 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

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



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

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

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


thanks,
Mukesh

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 3108 bytes --]

Is there any reason to not build gdbsx by default?

IOW does it affect performance?

-Bruce


On Thu, Jul 1, 2010 at 1:13 PM, Mukesh Rathor <mukesh.rathor@oracle.com>wrote:

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

[-- Attachment #1.2: Type: text/html, Size: 4637 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Keir Fraser]

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

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

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

 -- Keir

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 3822 bytes --]

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

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

That would simplify the downstream packaging. They wouldn't need to provide
an additional mechanism/hook/option to get gdbsx installed.
The current debian packaging patch is a widely used "get this onto my box"
aid, and it has no facility for tweaking the build options.

-Bruce


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

[-- Attachment #1.2: Type: text/html, Size: 6180 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Ian Jackson]

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.

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 1992 bytes --]

On Fri, Jul 2, 2010 at 9:53 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

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

--- xen-4.0-testing.hg-07.02.10/tools/Makefile  2010-07-02
10:30:40.000000000 -0700
+++ xen-4.0-testing.hg/tools/Makefile   2010-07-02 11:25:04.000000000 -0700
@@ -36,6 +36,7 @@
 SUBDIRS-y += libxl
 SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
+SUBDIRS-y += debugger/gdbsx

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

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

 XEN_ROOT=$(BASEDIR)/..

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

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

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

-Bruce


> Thanks,
> Ian.
>

[-- Attachment #1.2: Type: text/html, Size: 2987 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

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

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 2212 bytes --]

Forgot patch tag in subject ...

On Fri, Jul 2, 2010 at 3:41 PM, Bruce Edge <bruce.edge@gmail.com> wrote:

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

[-- Attachment #1.2: Type: text/html, Size: 3403 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Ian Jackson]

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.

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 1125 bytes --]

On Tue, Jul 6, 2010 at 4:57 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg
> and debugger  documentation."):
> > Here is a patch to enable gdbsx by default.
>
> Thanks.  Is it against 4.0-testing as it seems to be ?


Yes, it is.


> I think we
> probably want this against xen-unstable, against which your patch
> doesn't apply.
>

OK, I'll pull down an unstable tree and resubmit.

Thanks for the help.

-Bruce


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

[-- Attachment #1.2: Type: text/html, Size: 1972 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Bruce Edge]

[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]

On Tue, Jul 6, 2010 at 4:57 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg
> and debugger  documentation."):
> > Here is a patch to enable gdbsx by default.
>
> Thanks.  Is it against 4.0-testing as it seems to be ?  I think we
> probably want this against xen-unstable, against which your patch
> doesn't apply.
>

Ian, here's an unstable patch:

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

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

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

Thanks

-Bruce


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

[-- Attachment #1.2: Type: text/html, Size: 2778 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: State of gdbsx in xen-4.0-testing.hg and debugger documentation.

[Ian Jackson]

Bruce Edge writes ("Re: [Xen-devel] State of gdbsx in xen-4.0-testing.hg and debugger  documentation."):
> Ian, here's an unstable patch:

Thanks.  It still didn't apply to xen-unstable because it had had tabs
replaced with spaces, but I fixed it up.

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

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

Thanks,
Ian.

>From Documentation/SubmittingPatches:

        Developer's Certificate of Origin 1.1

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

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

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

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

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

--