Question: Why are the semaphore, mutex and byte pool _tx_*_created_count symbols mandatory (non-optional) for ThreadX detection?

[kennedyho-renesas]

Hi @raphaelmeyer ,

First of all, thank you very much for your contribution on the ThreadX support in RTOS Views, it has been incredibly useful and greatly benefits all ThreadX users.

While testing ThreadX detection in RTOS Views, I have noticed that tryDetect() looks for the following 4 mandatory symbols (all 4 need to exist at the same time) for ThreadX detection to be valid.

• _tx_thread_created_count
• _tx_semaphore_created_count
• _tx_mutex_created_count
• _tx_byte_pool_created_count

Reference: https://github.com/mcu-debug/rtos-views/blob/61ecf956b574f06f41964d0b7f8a113ddd71ec2b/src/rtos/rtos-threadx.ts#L158C1-L184C19

This seems to work fine for ThreadX applications that use all the 4 ThreadX objects.
However, for minimal or size-optimized ThreadX applications that do not create 1 or more of these objects, ThreadX is not detected.
For example, if the application does not create a mutex by calling tx_mutex_create(), the linker typically omits the mutex module entirely, which causes the _tx_mutex_created_count to not be included in the image. In this case, ThreadX detection will fail for RTOS Views even though the application is running ThreadX.

My questions regarding this would be:

• Is there a specific technical reason or design intent behind requiring all 4 symbols to be present for a ThreadX detection to be valid?
• Would it be possible to relax the rules for ThreadX detection, such that only _tx_thread_created_count is mandatory, and making other symbols for semaphore, mutex and byte pool symbols optional (opt for getVarIfEmpty set to true for example) so that minimal or size-optimized ThreadX applications can still be detected?

Please let me know your insights regarding this, and thank you once again for your contribution.

Best regards,
Kennedy

[haneefdm]

Probably an oversight by the author. Yes, only thread count should be required...others, can be empty tabs indicating they are available if FW uses them, but should make the distinction of zero items vs not in FW at all ... if that is feasible.

I want to give the author @raphaelmeyer a chance to respond. If not, I would welcome a PR from @kennedyho-renesas . Lets give the author a couple of days to respond.

[kennedyho-renesas]

Hi @haneefdm , thank you very much for your input. I agree with you that we should wait for @raphaelmeyer 's input.

[raphaelmeyer]

Hi @kennedyho-renesas
Thanks for pointing this out.

Is there a specific technical reason or design intent behind requiring all 4 symbols to be present for a ThreadX detection to be valid?

No, I just did not consider that these symbols maybe omitted.

I would like to have a closer look at the detection functionality anyway, I think there are a few other problems as well. I intend to do so in the next few days/weeks. But PRs are always welcome.

[kennedyho-renesas]

Hi @raphaelmeyer , thank you very much for your clarification. I wanted to make sure I'm not changing anything that might go against your original intent.

I have created a PR for this: #93 which is just a very minor change, making _tx_semaphore_created_count, _tx_mutex_created_count and _tx_byte_pool_created_count optional in tryDetect(). Testing shows that tabs without the object created will just be blank.
I intend for this to be a quick fix for now, and will look into @haneefdm 's suggestion to making it more user friendly by providing text indication/hints.

Thank you for the insights and permission for me to make changes. Please do let me know if the quick fix in the PR is acceptable and if there are better ways to go around this.

[haneefdm]

Don't think you need any detailed text instructions. Just something like (example semaphores)

Not found in FW: Semaphores not compiled
Found zero: Zero semaphores currently used

Just an indication as to why the Tab is empty and an indication that if they do use them, they will show up.

When people see an empty tab, it can cause an Issue report and we would like to reduce that. So, selfish reasons :-)

Thanks btw, for everyone contributing. This extension is becoming popular and is now used by many debuggers besides my own.

[kennedyho-renesas]

Hi @haneefdm , @raphaelmeyer ,

Sorry for the slight delay. I have made some changes to the PR: #93 based on the feedbacks.
Would appreciate if you could review it when you have some time, and do let me know if I need to fix anything.
Many thanks.

Best regards,
Kennedy

[kennedyho-renesas]

Closed the issue as the PR has been merged: #93