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 1:47 PM, Bruce Edge <bruce.edge@xxxxxxxxx> wrote:

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.

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