Cross compile program which uses pthreads for bare metal

0
votes

OK, this might be a very general question but I'm not to familiar with the topic and happy for any hint.

I have a Cross Compiling tool chain from SoucereyCodeBench for ARM ( arm-xilinx-linux-gnueabi-). I cross compiled a library which uses the compiler Options: -DSC_INCLUDE_FX -DSC_USE_PTHREADS -pthreads -fPIC -DPIC

So if I want to use the libary for bare metal program I would need pthreads for the bare metal compiler (arm-xilinx-eabi-) I guess?

Otherwise my program probally wouldn't run or compile in the first place. So could it be done to compile pthreads for bare metal?

2
embeddedarmxilinxbare-metal
Who is going to manage the threads on a bare-metal project? Basically, you need an OS to do this, and then you don't have bare-metal project anymore. – artless noise
You may be interested in Threading using setjmp()/longjmp(), but this is not pthreads. You could do some limited multi-tasking or threading this way; generally known as user-space threading. However, if you expect full blown pthreads, then you might as well have an OS. In a bare metal context, user-space threading is a primitive OS. – artless noise
I tried an 8MB busy box from ram, but it contains some processes interrupting my applicatin so it hangs ervery 2 secounds. I couln't figure out wich and changed run priority with nice and closed all processes beside the kernel with no luck. – eactor
If you have busybox (the lightweight shell suite), I'd expect you are running linux and have pthread support. So why are you calling this bare metal development? Or explain what other thing you mean by "BusyBox" – Chris Stratton
The hanging is the reason why I want to switch to bare metal. – eactor

2 Answers

4
votes

I think it will be a matetr of porting your code rather than simply cross-compiling it unchanged. As its name suggests POSIX threads (pthreads) assumes a POSIX API.

If you need threads on a bare metal ARM target, the you at least need some sort of thread scheduling libraries of which there are many. Most RTOSs are not full OSs in the sense of Linux, but rather simple schedulers with IPC mechanisms that link as static libraries like any other to your monolithic application - that probably still counts as "bare metal" in the sense that the system boots directly to your main() function where you are responsible for creating tasks/threads and starting the scheduler.

Some RTOSs support POSIX APIs and therefore pthreads, but these tend to be the larger more complete OSs rather than simple schedulers - either way they are generally smaller and more scalable then Linux so may meet yout "bare metal" requirements nonetheless.

Of course nothing stops you from creating a wrapper around any RTOS library to provide a pthread compatible API that might make porting your code simpler.

5
votes

Threads and Bare Metal

Bare metal programming targets only provide what you put on them. The pthread implementation most folks are familiar with is the Linux NPTL version, which works because the Linux kernel and the GNU C library make it work. On bare metal targets, you don't get the benefit of either the Linux kernel or the GNU C library. You'll have to bring your own bare metal thread library and runtime but at that point you may be better off using an RTOS that provides threads.

A Note on Toolchain Prefixes

The gcc toolchain prefix, arm-xilinx-linux-gnueabi-, indicates the target as ARM Linux, not bare-metal. The arm-xilinx-linux-gnueabi- toolchain will build pthread aware code (-lpthread) but it will assume that the Linux target has the pthread library and other necessary software layers already installed.

If instead you switch to the bare-metal version of the gcc ARM xilinx toolchain, your toolchain prefix will be arm-xilinx-eabi-. Everything I said above about bare metal and threads will apply.