Re: [tcf-dev] Services and the memory map

[Eugene Tarassov <eugenet@xxxxxxxxxx>]

The target side mapping data is edited at the data origin, in this case, in your back-end code.
It is your code, you decide how to store the data, you implement the editing any way you want, and you provide any API you need.
After the data changes, you call memory_map_event_mapping_changed() to notify the agent and remote clients.
The service will lazily call context_get_memory_map() to read new mapping data from you.

> is there some other "preferred" way to add to the container that sources the context_get_memorymap()?

I'm not sure what you mean.
context_get_memory_map() is your function.
In the function body, you construct the MemoryMap object - just add whatever you need to add.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Gherzan, Mircea
Sent: Monday, November 23, 2020 1:03 PM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: Re: [tcf-dev] Services and the memory map

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.


Thank you, Eugene. Now, please, how about the case where the mappings should be immutable/read-only from the Eclipse GUI point of view? Should the service logic invoke a context_add_region() exposed via the ContextExtIf? Or is there some other "preferred" way to add to the container that sources the context_get_memorymap()?

Regards,
- Mircea

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Eugene Tarassov
Sent: Thursday, November 19, 2020 2:58 AM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: Re: [tcf-dev] Services and the memory map

Hi Mircea,

For the mappings to be editable by the user in the Eclipse GUI, the proper use is:

C. The command reply provides an array of MemoryRegion objects, then the reply handler adds the regions to the launch attribute TCFLaunchDelegate.ATTR_MEMORY_MAP. The Eclipse GUI logic sends a MemoryMap.set when the attribute changes. The attribute can be edited with the Symbol Files dialog or by any custom logic.

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Gherzan, Mircea
Sent: Wednesday, November 18, 2020 4:08 PM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: [tcf-dev] Services and the memory map

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,

Please, can you shed some light about the _proper_ use of the MemoryMap API? Here's the scenario: an user clicks a button in the Eclipse GUI, which results in the invocation of a custom TCF service command, with the final end-user result that some modules get automagically loaded in the Modules view for the selected context. The service command in the agent uses the context_() API to find some (PE/COFF, ELF) modules on the desired context. The resulted modules mappings should be editable by the user in the Eclipse GUI. My question, please: what is the "proper" TCF way to achieve this? I see two options:

A. The command reply provides an array of MemoryRegion objects, then some custom Eclipse GUI logic send a MemoryMap.set with them included.
        Pro: pretty clean, no breaking of semantics/stacking
        Con: round-trip to the GUI and back

B. The service logic in the agent gets some "side-band" write access to the data container that "feeds" the context_get_memory_map() of the desired context, so the modules land in the "target" map.
        Pro: smaller round-trip (an event would still be needed though to tell the GUI client to "pull" the new mappings)
        Cons:
                1. module entries not editable by the end-user because they are part of the "target" map.
                2. breaking the API/stacking, as there's direct access from a service to a context-specific implementation detail

Are there any other ways?

Thanks in advance,
- Mircea

_______________________________________________
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
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tcf-dev