[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] Configuring Linux TCF agent to stop all threads of a process instead of current one
|
Hi Didier,
I vote for #1.
#3 can be added later, while #1 would select default mode.
GDB calls it "all-stop mode", ENABLE_AllStopMode would be good name for the macro.
> I am also wondering if we should advertise this to the client
It should not be necessary for #1.
Regards,
Eugene
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Brachet, Didier
Sent: Tuesday, April 05, 2016 5:24 AM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] Configuring Linux TCF agent to stop all threads of a process instead of current one
Hello,
I would like to configure the Linux TCF agent to stop all threads of a
process when a breakpoint is hit (or when a suspend thread request is
sent). This is pretty easy to do by simply updating the
context_get_group() in context-linux.c to return ctx->mem instead of ctx
for CONTEXT_GROUP_INTERCEPT group but I am wondering how to integrate
this in Open Source TCF agent without breaking current behavior. I see
several solutions to do this:
1 - Introduce a new build macro ENABLE_INTERCEPT_GROUP (e.g.) and make
use of this macro in context-linux.c to configure behavior of
context_get_group().
2 - Make use of context-mux.h to overload context_get_group() interface
3 - Make this dynamically configurable by the client using a dedicated
RunControl interface
I suspect 3 would be pretty difficult to implement since it would
potentially impact existing attachment (before the configuration is
updated) and I am not sure how to handle this correctly.
Solution 2 would be okay but I think this behavior is something that can
be useful to others and using context-mux.h to do this is a little bit
overkill (and make break usage of context-mux.h for its original purpose
if we want to enable both features)
I would vote to implement solution 1 but I wanted to get general
agreement before I do this. I am also wondering if we should advertise
this to the client but I am not sure this is really needed since the
client should react to the events it receives.
Any feedback is welcome
Regards,
Didier
--
Didier Brachet, Principal Technologist, Wind River
direct (33) 297.427.286 fax (33) 297.424.550
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
