View email archives for the history of this mailing list.
systemc-forum - Re: [Systemc-forum] Quickthreads problems on Linux platform using Pthrea
- To: "Carey, Patrick" <patrick.carey@xxxxxxxxx>
- From: "Ballance, Matt" <matt_ballance@xxxxxxxxxxx>
- Date: Wed, 04 Feb 2004 09:42:49 -0800
- Cc: systemc-forum@xxxxxxxxxxx
- Send Email to firstname.lastname@example.org:
- Send new message
- Reply to this message
I have run into this issue, but not with SystemC specifically.
The details are that the Linux pthread library uses the current
stack-pointer to determine which thread (pthread) is currently
executing. When the stack pointer is within the user-thread's malloc'd
stack block, the pthread lib isn't able to determine which pthread is
currently running. Usually this causes a crash.
I believe that glibc/pthreads can be configured to use a processor
register for threadId rather than the stack pointer. I haven't fully
explored this approach, since in my application I cannot require a
The workaround that I eventually applied was to allocate all
user-thread stacks from the main application stack. For you, this would
entail customizing the SystemC library to use your own stack
Hope this is helpful...
On Wed, 2004-02-04 at 08:40, Carey, Patrick wrote:
> Has anyone had any success in getting SystemC threads (SC_THREADS) to
> work on top of a system running Pthreads on Linux? I know from the
> past few years that there was an issue with the Linux Pthread library
> in its handling of certain pointers on the stack that causes errors
> with malloc. We have a validation system where the base executable is
> running Pthreads and this program kicks off other tools, one of which
> is a SystemC design that has test threads in it. The test threads seg
> fault with malloc due to the incompatibility described above. Does
> anyone know if it is possible to reimplement the Pthreads library or
> any other workaround so these two thread systems can coexist?
> Patrick Carey
Matt Ballance <matt_ballance@xxxxxxxxxxx>