From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 0/2] 32bit gdbserver-xen/libxc to debug 64bit guest Date: Fri, 02 Nov 2007 16:35:45 -0700 Message-ID: <472BB451.4010603@oracle.com> References: Reply-To: mukesh.rathor@oracle.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Keir Fraser Cc: "Kurt C. Hackel" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 2/11/07 02:14, "Mukesh Rathor" 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.