gdbsx?

gdbsx?

[Jun Koi]

Hi,

A talk about gdbsx at the last summit looks very useful. Is there any
roadmap to include it into the tree? Or at least some supports for it
is merged, so it can stay outside the tree if that is more desired?

Thanks,
Jun

Re: gdbsx?

[Keir Fraser]

It's being maintained as an external repository:
http://xenbits.xensource.com/ext/debuggers.hg.

Unfortunately it apparently isn't a clone of xen-unstable.hg but a 3-month
old copy which has not since been resynchronised. Mukesh: I would recommend
you maintain a patch queue or a tree whose parent is xen-unstable.hg, which
you can periodically pull from and re-merge your patches. Otherwise you have
a debugger for an old fixed version of xen-unstable.hg which is rather less
useful in the long run.

 -- Keir

On 1/9/08 16:59, "Jun Koi" <junkoi2004@gmail.com> wrote:

> Hi,
> 
> A talk about gdbsx at the last summit looks very useful. Is there any
> roadmap to include it into the tree? Or at least some supports for it
> is merged, so it can stay outside the tree if that is more desired?
> 
> Thanks,
> Jun
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: gdbsx?

[Jun Koi]

On Tue, Sep 2, 2008 at 1:06 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> It's being maintained as an external repository:
> http://xenbits.xensource.com/ext/debuggers.hg.
>
> Unfortunately it apparently isn't a clone of xen-unstable.hg but a 3-month
> old copy which has not since been resynchronised. Mukesh: I would recommend
> you maintain a patch queue or a tree whose parent is xen-unstable.hg, which
> you can periodically pull from and re-merge your patches. Otherwise you have
> a debugger for an old fixed version of xen-unstable.hg which is rather less
> useful in the long run.

So it have a good chance to be merged? Cool!

Mukesh: Could you explain a bit the advantage of gdbsx over the
current implementation that is already in tree? I figured out some,
but still might miss some. That is not very clear from the slides.

Thanks,
J



> On 1/9/08 16:59, "Jun Koi" <junkoi2004@gmail.com> wrote:
>
>> Hi,
>>
>> A talk about gdbsx at the last summit looks very useful. Is there any
>> roadmap to include it into the tree? Or at least some supports for it
>> is merged, so it can stay outside the tree if that is more desired?
>>
>> Thanks,
>> Jun
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>

Re: gdbsx?

[Keir Fraser]

On 1/9/08 17:15, "Jun Koi" <junkoi2004@gmail.com> wrote:

>> Unfortunately it apparently isn't a clone of xen-unstable.hg but a 3-month
>> old copy which has not since been resynchronised. Mukesh: I would recommend
>> you maintain a patch queue or a tree whose parent is xen-unstable.hg, which
>> you can periodically pull from and re-merge your patches. Otherwise you have
>> a debugger for an old fixed version of xen-unstable.hg which is rather less
>> useful in the long run.
> 
> So it have a good chance to be merged? Cool!

It has some chance, if it is used and if it is cleanly implemented. Equally
for now it ought to be able to live quite happily outside of the main
repository.

 -- Keir

Re: gdbsx?

[Mukesh Rathor]

yeah, I've been meaning to refresh for a while now, but time just flies
by. Anyhoo, the ext tree is refreshed now. I did it in two steps so that
one could easily come up with a patch for 3.3.0 and another refresh to
latest.

Hopefully, any time soon, I'll stop spending time on dealing with time issues
in debugger and have the time to put patches somewhere in timely manner,
because its no fun when time goes backwards, or forwards so faaast...

thanks, Mukesh


Keir Fraser wrote:
 > It's being maintained as an external repository:
 > http://xenbits.xensource.com/ext/debuggers.hg.
 >
 > Unfortunately it apparently isn't a clone of xen-unstable.hg but a 3-month
 > old copy which has not since been resynchronised. Mukesh: I would recommend
 > you maintain a patch queue or a tree whose parent is xen-unstable.hg, which
 > you can periodically pull from and re-merge your patches. Otherwise you have
 > a debugger for an old fixed version of xen-unstable.hg which is rather less
 > useful in the long run.
 >
 >  -- Keir
 >
 > On 1/9/08 16:59, "Jun Koi" <junkoi2004@gmail.com> wrote:
 >
 >> Hi,
 >>
 >> A talk about gdbsx at the last summit looks very useful. Is there any
 >> roadmap to include it into the tree? Or at least some supports for it
 >> is merged, so it can stay outside the tree if that is more desired?
 >>
 >> Thanks,
 >> Jun
 >>
 >> _______________________________________________
 >> Xen-devel mailing list
 >> Xen-devel@lists.xensource.com
 >> http://lists.xensource.com/xen-devel
 >

Re: gdbsx?

[Mukesh Rathor]

 >Mukesh: Could you explain a bit the advantage of gdbsx over the
 >current implementation that is already in tree? I figured out some,
 >but still might miss some. That is not very clear from the slides.

I've not used the current implementation in the tree so can't compare.
The main reason for gdbsx is because we use 32bit dom0 on 64bit hypervisor,
and I couldn't get libxc to support that after a lot of effort.

What I can tell you about gdbsx is, it's a clean, simplified, lightweight
implementation, that relies on the hyp for most of the work with minimal
changes. It supports all guests, PV or HVM, 32bit or 64bit.


Keir Fraser wrote:
 > On 1/9/08 17:15, "Jun Koi" <junkoi2004@gmail.com> wrote:
 >
 > It has some chance, if it is used and if it is cleanly implemented. Equally
 > for now it ought to be able to live quite happily outside of the main
 > repository.
 >
 >  -- Keir

gdbsx currently works on 32bit dom0 running on 64bit hyp, hence, probably
not ready for the main repo. OTOH, kdb is getting there....

thanks,
mukesh

Re: gdbsx?

[Jun Koi]

On Thu, Sep 4, 2008 at 7:57 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>
>>Mukesh: Could you explain a bit the advantage of gdbsx over the
>>current implementation that is already in tree? I figured out some,
>>but still might miss some. That is not very clear from the slides.
>
> I've not used the current implementation in the tree so can't compare.
> The main reason for gdbsx is because we use 32bit dom0 on 64bit hypervisor,
> and I couldn't get libxc to support that after a lot of effort.
>
> What I can tell you about gdbsx is, it's a clean, simplified, lightweight
> implementation, that relies on the hyp for most of the work with minimal
> changes. It supports all guests, PV or HVM, 32bit or 64bit.

Thanks. I will look at the code and get back if I have more questions.

>
>
> Keir Fraser wrote:
>> On 1/9/08 17:15, "Jun Koi" <junkoi2004@gmail.com> wrote:
>>
>> It has some chance, if it is used and if it is cleanly implemented.
>> Equally
>> for now it ought to be able to live quite happily outside of the main
>> repository.
>>
>>  -- Keir
>
> gdbsx currently works on 32bit dom0 running on 64bit hyp, hence, probably
> not ready for the main repo. OTOH, kdb is getting there....
>

gdbsx can happily stay outside tree as long as your changes to
hypercalls are merged. So it is important to get those hypercalls in.

Thanks,
Jun