Hi David,
I’m not sure I understand the problem.
It looks like you are modifying client_map.
You absolutely should not do that.
It is a shadow copy of a remote clients data, agent must not modify it.
The agent side of the memory map is called target_map.
The agent has full control of the target_map contents.
Regards,
Eugene
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx>
On Behalf Of Wilson, David
Sent: Monday, November 9, 2020 4:09 AM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: Re: [tcf-dev] API for Changing breakpoints
CAUTION: This message has originated from an External Source. Please use proper judgment and caution
when opening attachments, clicking links, or responding to this email.
Hi Eugene – thanks for the info – that indeed works well, and as expected. The problem we have with using a context changed event is that the client memorymaps
also gets cleared. This is because we cannot add to the client_map_list object in memorymap.c, meaning this does not contain the memorymap that we are adding to in the core (programmatically). We use the memory_map_get function to get the client_map for the
context, but this does not seem to have updated the client_map_list (only seems to be called by the “set” command).
Is there an upstream way to add to this list without calling the set command?
Best,
David Wilson
Hi David,
Regardless of how change_breakpoint_attributes() is implemented, it cannot be used to send information back to clients.
In the Breakpoints service, by definition, data sent from a client to the service is called "attributes", data sent back from the service to the client is called "status".
To report "unplanted because of reset" state you have to use "status" functionality of the service.
Actually, with proper implementation of the debugger back-end, it should just work without any changes, like this:
1. when target reset is activated, back-end sends "context changed" notification
2. on "context changed", the Breakpoints service tries to re-plant breakpoints and gets "Reset" error from the back-end
3. the Breakpoints service sends breakpoint status with "Reset" error to the client
4. client GUI shows a red overlay on the breakpoint icon, with annotation, which says "Cannot plant breakpoint: Reset"
5. when target reset is deactivated, same sequence without error.
Regards,
Eugene
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Wilson, David
Sent: Wednesday, November 4, 2020 8:37 AM
To: 'TCF Development' <tcf-dev@xxxxxxxxxxx>
Subject: [tcf-dev] API for Changing breakpoints
CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
Hi All,
I would like to discuss an API change for the breakpoints service.
First, let me describe the problem - on intel x86 platforms - when the target is reset, certain types of breakpoints will become unplanted. I need to reflect this, both in the clients.
I would like to use the exposed iterate_breakpoints and change_breakpoint_attributes functions.
For this to work, The BreakpointInfo struct will likely also need to be defined in this header (to implement the custom callback).
The problem is, I am finding the change_breakpoint_attributes function to not function as (I) expected. In the set_breakpoint_attributes that is called from change_breakpoint_attributes, If I just give the new attribute (i.e. no list), it seems to only store
that attribute, and remove all others.
Otherwise if I give the complete list, with one attribute changed, let's say BREAKPOINT_ENABLED to False, it seems to unset all parameters (such as ID) that have not changed. Am I using this function incorrectly? Even then, it still does not seem to unplant
the breakpoint in the GUI (i.e. the client).
I get the functionality I want by doing the following - looping through all breakpoints: on each breakpoint:
set_breakpoint_attribute -> replant_breakpoint -> send_event_context_changed on the breakpoint.
This is the behavior is what I would expect the changed_breakpoint_attributes function to do, but does not seem to be the case.
Any help is much appreciated.
Kind Regards
David Wilson
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tcf-dev
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
|
