Description
While ThreadX's linux/gnu port has 64-bit support, NetX Duo's does not. NetX Duo can still be successfully compiled to a 64-bit library, albeit with many -Wint-to-pointer-cast warnings due to casts from ULONG to pointer. However, using any features that rely on said casts will cause a SIGSEGV at runtime.
- Target device: 64-bit Linux host
- Eclipse ThreadX version: Any
- Toolchain and environment: CMake 4.1.2 using GCC 15.2 on x86_64 Linux
- Diagnosis and to reproduce: Use any features that rely on pointers being the same size as ULONG, such as
_nx_web_http_client_connect, which calls _nx_ip_fast_periodic_timer_entry, which relies on that assumption.
- Workaround: Compile ThreadX and NetX Duo as 32-bit instead.
Expected behaviour
Rather than crashing at runtime or emitting warnings, NetX Duo should throw a compilation error if targeting a port where ULONG and pointers have different lengths.
Impact
This issue prevents compiling a ThreadX application using NetX Duo on a 64-bit Linux hosts, which would be quite useful for testing and validation, such as CI/CD.
Logs and console output
Compilation warning:
[94/915] Building C object _deps/stm32-mw-netxduo-build/CMakeFiles/netxduo.dir/common/src/nx_ip_fast_periodic_timer_entry.c.o
In file included from /home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-netxduo-src/common/src/nx_ip_fast_periodic_timer_entry.c:28:
/home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-netxduo-src/common/src/nx_ip_fast_periodic_timer_entry.c: In function '_nx_ip_fast_periodic_timer_entry':
/home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-netxduo-src/common/inc/nx_api.h:205:71:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
205 | (a) = (b *)(c); \
| ^
/home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-netxduo-src/common/src/nx_ip_fast_periodic_timer_entry.c:83:5: note: in expansion of macro 'NX_TIMER_EXTENSION_PTR_GET'
83 | NX_TIMER_EXTENSION_PTR_GET(ip_ptr, NX_IP, ip_address)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Which leads to this crash. GDB output:
/home/lavy2504/git-repos/threadx-project/tests/test_nx_web_http_client_connect.cpp:73: FAILED:
{Unknown expression after the reported line}
due to a fatal error condition:
SIGSEGV - Segmentation violation signal
===============================================================================
test cases: 2 | 1 passed | 1 failed
assertions: 2 | 1 passed | 1 failed
Thread 3 "threadx.project.tests" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6ffe6c0 (LWP 1268491)]
0x0000555555648c5b in _tx_event_flags_set (group_ptr=0x5568d1b0, flags_to_set=256, set_option=<optimized out>) at /home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-threadx-src/common/src/tx_event_flags_set.c:142
142 if (group_ptr -> tx_event_flags_group_suspended_count != TX_NO_SUSPENSIONS)
(gdb) bt
#0 0x0000555555648c5b in _tx_event_flags_set (group_ptr=0x5568d1b0, flags_to_set=256, set_option=<optimized out>) at /home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-threadx-src/common/src/tx_event_flags_set.c:142 #1 0x000055555564b785 in _tx_timer_thread_entry (timer_thread_input=<optimized out>) at /home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-threadx-src/common/src/tx_timer_thread_entry.c:307
#2 0x000055555564a677 in _tx_thread_shell_entry () at /home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-threadx-src/common/src/tx_thread_shell_entry.c:114
#3 0x000055555564cac6 in _tx_linux_thread_entry (ptr=0x5555556dcd80 <_tx_timer_thread>) at /home/lavy2504/git-repos/threadx-project/build/Debug/_deps/stm32-mw-threadx-src/ports/linux/gnu/src/tx_thread_stack_build.c:151
#4 0x00007ffff789dd53 in start_thread () from /lib/libc.so.6
#5 0x00007ffff792563c in __clone3 () from /lib/libc.so.6
(gdb) x 0x5568'd1b0
0x5568d1b0: Cannot access memory at address 0x5568d1b0
(gdb) x 0x5555'5568'd1b0
0x55555568d1b0 <client_ip+2608>: 0x4456444e
Additional context
Looking at other GitHub issues, I found a closed issue with the same problem from 2020: #7. Is 64-bit support still on the roadmap for NetX Duo? If yes, can you provide an expected timeline? Thank you! 😊
Description
While ThreadX's linux/gnu port has 64-bit support, NetX Duo's does not. NetX Duo can still be successfully compiled to a 64-bit library, albeit with many
-Wint-to-pointer-castwarnings due to casts fromULONGto pointer. However, using any features that rely on said casts will cause aSIGSEGVat runtime._nx_web_http_client_connect, which calls_nx_ip_fast_periodic_timer_entry, which relies on that assumption.Expected behaviour
Rather than crashing at runtime or emitting warnings, NetX Duo should throw a compilation error if targeting a port where
ULONGand pointers have different lengths.Impact
This issue prevents compiling a ThreadX application using NetX Duo on a 64-bit Linux hosts, which would be quite useful for testing and validation, such as CI/CD.
Logs and console output
Compilation warning:
Which leads to this crash. GDB output:
Additional context
Looking at other GitHub issues, I found a closed issue with the same problem from 2020: #7. Is 64-bit support still on the roadmap for NetX Duo? If yes, can you provide an expected timeline? Thank you! 😊