Re: [tcf-dev] TCFLaunch.onConnect() and other steps

[Eugene Tarassov <eugene.tarassov@xxxxxxxxxx>]

Hi Stefan,

> onConnect() in TCFLaunch. As far as I can see this method does a lot of things I won't need in for my agent.

There should be no need to change that code. If you don't want to start a process, don't set TCFLaunchDelegate.ATTR_REMOTE_PROGRAM_FILE and related attributes in the launch configuration.

> After programming the device, another command is sent that tells my ControllerService to run that program until one of the breakpoints are hit e.g. runUntil(byte[] bpAdressArray).

In Eclipse, breakpoints are managed by IBreakpointManager, so the right way to do it is to register a breakpoint with the manager. Usually the breakpoint is set on a function (e.g. "main"), not at an address. Then the target is resumed. When the breakpoint is hit, the debugger will show that to user.

> I am thinking of another thread - since runUntil() is blocking - that waits for this event.

TCF APIs are more suitable for event-driven code.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan.Falk@xxxxxxxxxxxx
Sent: Tuesday, February 18, 2014 4:24 AM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] TCFLaunch.onConnect() and other steps

Hi!

So far I am able to program a controller using the communication chain Eclipse -> TCF -> ControllerServer. My problem now is that I am not sure how to run this program. I don't understand how the original agent did that. I see that it subscribes to some streams e.g. "Processes",  "ProcessesV1", .. then did a few reads and at some point command_start() from processes.c gets called.

It is clear to me that I will have to replace this whole part. There is onConnect() in TCFLaunch. As far as I can see this method does a lot of things I won't need in for my agent. Should I override that method too and subscribe to my own channel(s) for any further communication? Unfortunately I am not quite sure at the moment what those streams are exactly needed for..

Right now I think about doing it this way:

After programming the device, another command is sent that tells my ControllerService to run that program until one of the breakpoints are hit e.g. runUntil(byte[] bpAdressArray).

As a breakpoint gets reached, my agent will somehow have to be noticed. I am thinking of another thread - since runUntil() is blocking - that waits for this event. As it receives the address of the hit breakpoint I can pass all remaining information to the Eclipse easily.

And of course I hope that I can manage it somehow to integrate all debug information such that in the end my agent just remaps the address to a filename:row pair such that stepping actually works without having to reinvent stuff that the original agent is capable of already.


If anyone has some hints or pointer for me I'd be very happy!

Thank you and best regards,
Stefan Falk

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
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.