Xen devel - Nov 2007 - [PATCH 0/2] 32bit gdbserver-xen/libxc to debug 64bit guest

Hi Folks,

  Please allow me to submit my first patch set. The main purpose is to allow a 
32bit dom0 to support debug of a 64bit guest via gdbserver-xen. This also 
fixes gdbserver-xen not attaching to a 32 PAE guest.

Description:
  At present libxc and gdbserver-xen are compiled on the same architecture 
that dom0 is, ie, 32bit or 64bit. As a result, when 32bit binary is run on 
dom0 to attach to a 64bit guest, the data structures are incorrect, and the 
process fails. This patch addresses that by :

    - introducing a new compiler directive, _GDB_CROSS_COMP that will create a 
32bit binary on an x86_64 system (by using -m32).

    - including x86_64 data structures if the above is defined.

    - changing long''s to long long''s in relevant cases if the
above is defined.

    - linking libxc statically to the gdbserver-xen binary if above is defined.

The process is explained in the debugger/gdb/README file. The patch set is 
divided in three parts:
    - part 0 : description + libxc/xen related changes
    - part 1 : files changed in gdbserver xen-sparse tree.
    - part 2 : new files in gdbserver xen-sparse tree.

Please note, to achieve the above, an ifdef had to be added to user.h. This 
forced it to be copied locally. As a result, files that included this header, 
had also to be created/copied in the xen-sparse tree from the gdbserver tree 
to include local user.h.

Finally, mkbuildtree fixes "find" warning in the new version, and is
not
related to the patch objectives.


In summary, files changed are:
  config/x86_64.mk
  tools/libxc/xc_ptrace.c
  tools/libxc/xenctrl.h
  tools/libxc/xc_ptrace.h
  tools/libxc/xg_private.h
  xen/include/public/arch-x86/xen.h
  xen/include/public/arch-x86/xen-x86_32.h
  xen/include/public/foreign/mkheader.py
  xen/include/public/domctl.h

  tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/linux-xen-low.c
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/Makefile.in
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/mkbuildtree
  tools/debugger/gdb/gdbbuild
  tools/debugger/gdb/README

  tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/linux-x86-64-low.c
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdb_proc_service.h
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/amd64-linux-nat.c
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/linux-proc.c
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/bfd/elf.c
  tools/debugger/gdb/gdb-6.2.1-xen-sparse/include/user.h


Testing:
    After the above patch, I was able to build three binaries and attach to 
32bit, 32bit PAE, and 64bit guests on a 32bit dom0, and was able to set 
breakpoints, see stacks, step, walk the task list, and set correct 32bit/64bit 
values for global long variables.

Thanks a lot,
Mukesh Rathor



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

On 2/11/07 02:14, "Mukesh Rathor" <mukesh.rathor@oracle.com>
wrote:
> Please note, to achieve the above, an ifdef had to be added to user.h. This
> forced it to be copied locally. As a result, files that included this
header,
> had also to be created/copied in the xen-sparse tree from the gdbserver
tree
> to include local user.h.
The sparse tree should be overlaid a normal full gdbserver tree, so user.h
should be in the same place whether you''ve modified it or not. So I
don;t
see why you''d need to pull in every file that includes user.h.

The 32-on-64 compat layer inside Xen already builds 32-bit versions of
structures when building 64-bit Xen. I think they''re under
include/compat/
or something like that. It would make sense to make use of those rather than
hack up the original headers with explicit compat types.

 -- Keir



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

Keir Fraser wrote:
 > On 2/11/07 02:14, "Mukesh Rathor"
<mukesh.rathor@oracle.com> wrote:
 >
 >> Please note, to achieve the above, an ifdef had to be added to user.h.
This
 >> forced it to be copied locally. As a result, files that included this
header,
 >> had also to be created/copied in the xen-sparse tree from the
gdbserver tree
 >> to include local user.h.
 >
 > The sparse tree should be overlaid a normal full gdbserver tree, so user.h
 > should be in the same place whether you''ve modified it or not. So
I don;t
 > see why you''d need to pull in every file that includes user.h.

You are correct, I fixed it and will resubmit the patch, I guess with
a new email.

 > The 32-on-64 compat layer inside Xen already builds 32-bit versions of
 > structures when building 64-bit Xen. I think they''re under
include/compat/
 > or something like that. It would make sense to make use of those rather
than
 > hack up the original headers with explicit compat types.

I noticed that. But I am looking for 64bit struct versions when building 32bit
libxc. I figured coming with similar macros the other way would make the
whole think too complex, so adding explicit compat types made sense.
Besides, we kinda needed a debugger soon :).

 >  -- Keir

Thanks for your feedback and your time.

Mukesh Rathor
PS: I''ll be offline for a while. I can come up with enhancements in
future, or make further fixes, after I come back early Dec.


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

On 2/11/07 23:35, "Mukesh Rathor" <mukesh.rathor@oracle.com>
wrote:
>> The sparse tree should be overlaid a normal full gdbserver tree, so
user.h
>> should be in the same place whether you''ve modified it or not.
So I don;t
>> see why you''d need to pull in every file that includes user.h.
> 
> You are correct, I fixed it and will resubmit the patch, I guess with
> a new email.
The new patches look much better!
>> The 32-on-64 compat layer inside Xen already builds 32-bit versions of
>> structures when building 64-bit Xen. I think they''re under
include/compat/
>> or something like that. It would make sense to make use of those rather
than
>> hack up the original headers with explicit compat types.
> 
> I noticed that. But I am looking for 64bit struct versions when building
32bit
> libxc. I figured coming with similar macros the other way would make the
> whole think too complex, so adding explicit compat types made sense.
> Besides, we kinda needed a debugger soon :).
Well, given we can build 64-bit domains from 32-bit dom0, I''m pretty
sure we
can work out how to interrogate their state from 32-bit dom0, without
needing to modify any of the public headers. I''m sure we can clean this
up
and get the improvements in without too much trouble.

 -- Keir



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