Compiling ThreadX with Clang for Arm9

Hi @Scott Azure RTOS , correct I am using ARM9.
Yes I do have a hardware timer running. The low level implementation is modified to provide scheduler with ticks with a period of 1 ms.
From the point of view that the tx_timer_thread_entry.c file is a generic C file it is of course strange that with GCC compiler it works but with Clang does not, taking into account that other files compiled with Clang work just fine.
However, I tell here what I see in the real situation. I compile all the sources with Clang having all the targets configured for our platform and the processor and the architecture, booting the firmware up it hangs on the main thread (with priority 0 the highest ) when I call _tx_thread_sleep. The debugging shows that it enters into a forever loop in the tx_timer_thread_entry.c file and never returns. First what comes to mind is that something must be wrong with our implementation, but the truthiness of that loses its meaning when I compile the only tx_timer_thread_entry.c file with GCC. So when I compile the tx_timer_thread_entry.c file with GCC and the rest of ThreadX files using Clang it works just great, nothing hangs.

NOTE: Adding more text here because when just 6 characters are left to write comment this chat does not post the comment... (Everywhere there is some bug)

You noticed it right there is something wrong with the timer when the "tx_timer_thread_entry.c" file is compiled with Clang. What I did while debugging was to compile the tx_timer_thread_entry.c file with GCC and comment out the call to _tx_timer_interrup. The behavior was the same hanged at the first sleep call in the main thread.
This leaves me with the idea that "tx_timer_thread_entry.c" is not a generic implementation.

Thanks,
Artur

Hi @Arthur Petrosyan - with the tx_timer_thread_entry.c file compiled with clang, can you step through it and tell me the execution path that it takes? There is no reason it should get stuck in the while loop. Also, do you have TX_TIMER_PROCESS_IN_ISR defined? I assume you do not have this symbol defined.
You might also want to step through the _tx_timer_interrupt function. This ISR should not resume the tx timer thread (via _tx_timer_expiration_process) until the timer is actually expired (e.g. your thread has slept for x number of ticks).

Hi @Scott Azure RTOS ,

Debugging the Clang's compiled assembly and compering it with GCC there were several instructions that were not there in clang's assembly. While comparing the assembly started to reduce the optimization level. So just compiled the "tx_timer_thread_entry" file with -O0 and it worked (works also with -O1 but higher then that is not working). As I have to compile all the sources with strict size optimization, compiled the "tx_timer_thread_entry" function with "__attribute ((optnone))" and now I have all the files optimized but the "tx_timer_thread_entry" which only contains the "tx_timer_thread_entry" function.
So we can say that the issue is solved and the issue is in Clang's optimization.
If ThreadX team is planning or will port using clang you can freely consider this ( there might be a good solution from your side).

However several confusing questions remain.

1. Why would the optimization impact only on the main thread sleep.
2. There are other ThreadX sources that contain loops and similar functionality to the "tx_timer_thread_entry" how could plane C code be optimized differently. (There must be something specific to the "tx_timer_thread_entry" function and loops)
3. Did you try tests with GCC higher optimization levels? there might be a problem too (though I don't see it in my case using GCC).

Thanks