Re: [tcf-dev] Next Step in RTEMS Support

[Joel Sherrill <joel@xxxxxxxxx>]

On Fri, Nov 13, 2020 at 3:49 PM Eugene Tarassov <eugenet@xxxxxxxxxx> wrote:

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.

I would like to use the generic implementation. 

Looking at the VxWorks code, create_context is called as part of the attach done event hook.

Do I automatically need to do that or there isn't a context to even be in the pid-hash.

I am guessing that VxWorks must have the attach event occur before the threads are added.

Would that make sense? 

 

> 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.

OK. This will take more research but doesn't sound like the immediate issue stopping the thread list from showing up. 

 

BTW, for host side symbols, you need to run and use symbols server on the host, see org.eclipse.tcf.agent/server.

This is good to know. 

Sorry if these questions seem stupid. I am at the bottom of a lot of software and trying to cipher out what happens on VxWorks to make it happen similarly. 

But if my guess of the operational use is right, the attach event occurs when someone loads their application onto a base image and then the task create events will work.

The most common operational use of RTEMS does not involve a base image and loaded application so there may be a difference. People will want to see all the threads in a statically linked RTEMS system.

Thanks.

--joel

 

Regards,

Eugene

 

 

From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Joel Sherrill
Sent: Friday, November 13, 2020 1:04 PM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: [tcf-dev] Next Step in RTEMS Support

 

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) {
    struct event_info * info = (struct event_info *)arg;
    Context * current_ctx = context_find_from_pid(info->current_ctx.ctxId, 1);
    Context * stopped_ctx = context_find_from_pid(info->stopped_ctx.ctxId, 1);

context_find_from_pid() appears to always return NULL for me. I added prints and always see this:

 

In event_handler current_ctx=0
In event_handler - EVENT_TASK_ADD  

 

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

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tcf-dev