On Wed, 14 Jul 2010 16:17:16 -0700
Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 14 Jul 2010 07:29:46 -0700
> Bruce Edge <bruce.edge@xxxxxxxxx> wrote:
>
> > On Thu, Jul 1, 2010 at 3:08 PM, Mukesh Rathor
> > <mukesh.rathor@xxxxxxxxxx>wrote:
> >
> > > On Thu, 01 Jul 2010 23:54:34 +0200
> > > Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home