| Re: [tcf-dev] Next Step in RTEMS Support |
|
Hi Joel, > context_find_from_pid() appears to always return NULL for me. It is empty stub in context-rtems.c. You need to implement it. Or, you can use generic implementation of context_find_from_pid - add #include <tcf/framework/pid-hash.h> in context-rtems.c Or copy/paste the code if you need to modify it for RTEMS. > If the UI side translated the start method name into an address for the target No, you need to translate name into an address in start_process_imp() using find_symbol_by_name(). The find_symbol_by_name function will talk to the host to get symbol information. The function can throw “cache miss” exception, which might need special handling, see cache_enter()/cache_exit() description. BTW, for host side symbols, you need to run and use symbols server on the host, see org.eclipse.tcf.agent/server. Regards, Eugene From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx>
On Behalf Of Joel Sherrill 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 After puzzling over this, I realized that the context-vxworks.c was the closest example to what should work with RTEMS. Most of the services mapped directly over and I put in stubs for the ones that did not but they are not called yet.
I am now at the point where there is something I need a some insight into to get hooked up correctly. I have hooked the RTEMS task create extension (similar to taskCreateHookAdd()) and use the same event thread model. The create hook posts an event which is processed by event_thread_func() (context-vxworks.c:688). The call to post_event()
occurs in the RTEMS version just like the VxWorks version and the event thread calls event_handler(). I think this code is exactly the same as in context-vxworks.c. Up until here, I think the flow is OK up to here. The event_handler() function has this: static void event_handler(void * arg) { context_find_from_pid() appears to always return NULL for me. I added prints and always see this: In event_handler current_ctx=0 And then it bails at the equivalent of what is line 657 in context-vxworks.c. I had temporarily disabled the Processes service because RTEMS does not have posix_openpt(), grantpt(), unlockpt(), or ptsname(). Looking in processes.c, I see VxWorks has its own implementation of start_process_imp(). But RTEMS does not
do symbols on the target like VxWorks so this "spawn a task" substitute model won't quite work either. If the UI side translated the start method name into an address for the target, it would work the same. But I don't know if that's an option or not. I added a stub implementation of start_process_imp() for RTEMS that doesn't do anything hoping that would help but no luck. It feels like I have made a lot of progress but not quite enough. It seems like I am not tripping a step that adds the Context to the pid hash map. And no threads are showing up on the UI side. We have prints in every method in context-rtems.c and nothing gets called except the events associated with the attempting to add the existing threads and newly created threads. What magic bit am I missing? Thanks. --joel RTEMS |