This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Mismatch in threadGroupId of different -list-thread-groups output
- From: Marc Khouzam <marc dot khouzam at ericsson dot com>
- To: "'gdb at sourceware dot org'" <gdb at sourceware dot org>
- Date: Tue, 22 Jun 2010 11:56:34 -0400
- Subject: Mismatch in threadGroupId of different -list-thread-groups output
Hi,
I just noticed something with HEAD with respect to thread group ids.
When I'm debugging a process, the groupId returned by
-list-thread-groups --available
^done,groups=[
...
{id="11210",type="process",description="/local/lmckhou/testing/a.out",user="lmckhou"}
...
is not the same for that same process as the one returned by
-list-thread-groups
^done,groups=[{id="i1",type="process",pid="11210",executable="/local/lmckhou/testing/a.out",cores=["2"]}]
I'm not sure of all the impacts of this or if it was by design.
One impact I can think of is that when presenting the user with a
list of available processes to attach to, it is interesting
to know which of those processes are already being debugged (maybe
to exclude them from the list), so a correlation between
the two command results is useful.
Of course, I can map 'pid' of one output with 'id' of the other, but I know
the 'id' is supposed to be opaque. Any idea on what the way forward
should be for this?
BTW, having the pid in the the output of "-list-thread-groups --available"
is very useful, even if it part of the opaque id. It would be bad to remove
that information.
With this in mind, one solution that I think may be good would be to add
a 'pid' field to the outptu of "-list-thread-groups --available".
Thanks
Marc