From: Jan Kiszka <kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [bug?] set pthread stack size broken
Date: Fri, 09 Dec 2005 20:58:33 +0100 [thread overview]
Message-ID: <4399E1E9.6000509@domain.hid> (raw)
In-Reply-To: <4399B477.6050101@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 3375 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Jan Kiszka wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Hi,
>>>>
>>>> something for the night: Can someone explain why normal pthreads can be
>>>> restricted to initially use only the stack size provided via
>>>> pthread_attr_setstacksize() while any rt-mapped thread (posix and
>>>> native) refuse to accept this? For a simple test, compile the attached
>>>> program one time as normal
>>>>
>>>> gcc -lpthread -o stacksize stacksize.c
>>>>
>>>> and the other time against xeno's posix skin
>>>>
>>>> gcc `xeno-config --posix-cflags` `xeno-config --posix-ldflags` \
>>>> -o stacksize.o stacksize.c
>>>>
>>>> Then compare the memory requirements of both processes - they should
>>>> differ by 2M, the stack size when pthread_attr_setstacksize is not
>>>> used.
>>>> Strange - and also critical when considering larger applications...
>>>
>>>
>>> This has been nailed down now to be some strange linker problem: while
>>> the standard version of the stacksize demo calls the latest
>>> pthread_create (__pthread_create_2_1 in glibc-2.3.x), the wrapped
>>> real-time version and likely also applications linked against libnative
>>> call an older pthread_create (__pthread_create_2_0). That variant
>>> assumes that pthread_attr_t does not yet contain things like the stack
>>> size and fills in the standard value again. :(
>>>
>>> Can anyone with another build environment than my SuSE 10 confirm this?
>>>
>>>
>>>> So far I only tested against 2.1, but I don't see a reason why 2.0.x
>>>> should behave different. Will get checked, though.
>>>>
>>>
>>> Same behaviour on 2.0.x (SVN).
>>>
>>> Jan
>>>
>>
>>
>> The attached patch fixes this issue for 2.1-SVN. A similar patch should
>> be applied to 2.0.x as well. And maybe it also hits the UVM, but this is
>> something I cannot assess ATM.
>>
>> Well, you know, the smaller the bug... :-/
>>
>> Jan
>>
>>
>> PS: For those you are interested why we need this, read
>>
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145941
>>
>> Found via google:"pthread_create NOTYPE" after I noticed the differences
>> in "readelf -s libnative.so".
>>
>>
>> ------------------------------------------------------------------------
>>
>> Index: src/skins/native/Makefile.am
>> ===================================================================
>> --- src/skins/native/Makefile.am (revision 243)
>> +++ src/skins/native/Makefile.am (working copy)
>> @@ -1,6 +1,6 @@
>> lib_LTLIBRARIES = libnative.la
>>
>> -libnative_la_LDFLAGS = -module -version-info 0:0:0
>> +libnative_la_LDFLAGS = -module -version-info 0:0:0 -pthread
>>
>> libnative_la_SOURCES = \
>> alarm.c \
>> Index: src/skins/posix/Makefile.am
>> ===================================================================
>> --- src/skins/posix/Makefile.am (revision 243)
>> +++ src/skins/posix/Makefile.am (working copy)
>> @@ -2,7 +2,7 @@
>>
>> lib_LTLIBRARIES = libpthread_rt.la
>>
>> -libpthread_rt_la_LDFLAGS = -module -version-info 0:0:0
>> +libpthread_rt_la_LDFLAGS = -module -version-info 0:0:0 -lpthread
>>
>> libpthread_rt_la_SOURCES = \
>> init.c \
>
>
> Applied (with -pthread everywhere), thanks.
>
Hmm, shouldn't is spell -lpthread? Seems like the autotools resolve this
because it works with both versions for me (current posix/Makefile.in
still has "-lpthread").
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
next prev parent reply other threads:[~2005-12-09 19:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-08 22:53 [Xenomai-core] [bug?] set pthread stack size broken Jan Kiszka
2005-12-09 7:24 ` Jan Kiszka
2005-12-09 16:19 ` Jan Kiszka
2005-12-09 16:44 ` Philippe Gerum
2005-12-09 19:58 ` Jan Kiszka [this message]
2005-12-10 10:45 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4399E1E9.6000509@domain.hid \
--to=kiszka@domain.hid \
--cc=rpm@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.