This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]