pthread_getattr_np does not work

Mon Sep 25 16:29:54 UTC 2017

I would suggest adding a test of another thread with a user provided stack
space that is properly aligned (e.g. array of double of minimum stack size
divided by sizeof(double)). This would give you known address range and
size for that thread.

For the case of RTEMS allocating the stack, the pointer returned to you
will vary based on the BSP and will essentially be random to the
application.
If the application allocates it, then it knows the starting address.

You should be able to add that to the existing test without much trouble.

--joel

On Sun, Sep 24, 2017 at 9:45 PM, xuelin.tian at qkmtech.com <
xuelin.tian at qkmtech.com> wrote:

> OK, I will try to do this.
>
> ------------------------------
> Best wishes,
> xuelin.tian at qkmtech.com
>
>
> *From:* Joel Sherrill <joel at rtems.org>
> *Date:* 2017-09-24 21:32
> *To:* xuelin.tian <xuelin.tian at qkmtech.com>
> *CC:* rtems-users at rtems.org <users at rtems.org>; Sebastian Huber
> <sebastian.huber at embedded-brains.de>
> *Subject:* Re: Re: pthread_getattr_np does not work
> No. But you are welcome to submit patches so the behavior matches Linux.
>
> On Sep 24, 2017 1:09 AM, "xuelin.tian" <xuelin.tian at qkmtech.com> wrote:
>
>> So, is there a substitute function for this in RTEMS, without modifying
>> the source code?
>>
>>
>> ------------------ Original ------------------
>> *From: * "Joel Sherrill"<joel at rtems.org>;
>> *Date: * Sun, Sep 24, 2017 00:15 AM
>> *To: * "xuelin.tian"<xuelin.tian at qkmtech.com>;
>> *Cc: * "Sebastian Huber"<sebastian.huber at embedded-brains.de>; "
>> users at rtems.org"<users at rtems.org>;
>> *Subject: * Re: Re: pthread_getattr_np does not work
>>
>>
>>
>> On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian <xuelin.tian at qkmtech.com>
>> wrote:
>>
>>> Thanks so much for your test.
>>>
>>
>> No problem. Just trying to help.
>>
>>
>>> The parts of this structure I care about most are the stackaddr and
>>> stacksize (and guardsize maybe), where stackaddr always returns 0. The
>>> value of stacksize is either 8192 or 0, based on the fact that this
>>> attribute structure is retrieved from POSIX_Init or other pthreads in my
>>> system (maybe I use pthread_create in a wrong way...).
>>>
>>
>> Without looking at the code, 8192 is almost certainly the port specific
>> default
>> stack size since it is normally a value like that. A stack size request
>> of anything
>> less than the recommended minimum will always get you an allocation of the
>> minimum. So 0 or 8192 might simply indicate whether the structure is
>> explicitly
>> initialized via pthread_attr_init() or filled in explicitly by the
>> application with
>> the minimum stack size constant.
>>
>>
>>>
>>> So, from the result you post, the stackaddr is 0 too, which means this
>>> element is not supported in rtems, or there is something wrong with this
>>> function?
>>>
>>
>> This means the user application didn't specify the stack area in RTEMS.
>> Since
>> this method is "NP", there is no standard specifying the behavior.
>>
>> This method doesn't exist on FreeBSD and appears to only exist in Linux
>> and
>> RTEMS. If there is consensus that it should behave the same on Linux and
>> RTEMS, then there should be a ticket filed with (hopefully) patches.
>> <hint>
>>
>> It isn't a complicated method and all if should take is filling in the
>> attribute
>> structure with different fields in the TCB. I think it primarily parrots
>> back
>> the attribute structure passed to pthread_create().
>>
>> Also writing the man page for the RTEMS POSIX manual would be appreciated.
>>
>> Nothing like wandering into something that is even beyond unspecified in
>> POSIX to a method that is explicitly non-portable for fun. :)
>>
>> --joel
>>
>> --joel
>>
>>>
>>>
>>> ------------------ Original ------------------
>>> *From: * "Joel Sherrill"<joel at rtems.org>;
>>> *Date: * Fri, Sep 22, 2017 10:15 PM
>>> *To: * "xuelin.tian at qkmtech.com"<xuelin.tian at qkmtech.com>;
>>> *Cc: * "Sebastian Huber"<sebastian.huber at embedded-brains.de>; "
>>> users at rtems.org"<users at rtems.org>;
>>> *Subject: * Re: Re: pthread_getattr_np does not work
>>>
>>> The test does verify the values. I don't see a specific case of creating
>>> a thread
>>> with a non-standard stack value and verifying that value in the task but
>>> the
>>> test creates a thread which retrieves its values and verifies many
>>> (most, all?)
>>> of them:
>>>
>>> (gdb)
>>> Thread - pthread_getattr_np - Verify value
>>> 46        sc = pthread_getattr_np( Thread_id, &attr );
>>> (gdb)
>>> 47        rtems_test_assert( sc == 0 );
>>> (gdb)
>>> 52        puts( "Thread - pthread_setschedparam: Setting highest
>>> priority SCHED_FIFO" );
>>> (gdb) p attr
>>> $1 = {is_initialized = 1, stackaddr = 0x0, stacksize = 8192,
>>>   contentionscope = 0, inheritsched = 2, schedpolicy = 2, schedparam = {
>>>     sched_priority = 3, sched_ss_low_priority = 285216961,
>>>     sched_ss_repl_period = {tv_sec = 0, tv_nsec = 16},
>>>     sched_ss_init_budget = {tv_sec = 0, tv_nsec = 1}, sched_ss_max_repl
>>> = 0},
>>>   guardsize = 0, cputime_clock_allowed = 1, detachstate = 1,
>>>   affinitysetsize = 0, affinityset = 0x0, affinitysetpreallocated = {
>>>     __bits = {0}}}
>>>
>>> Clearly the attribute structure returned is not all zero.
>>>
>>> I am not sure what you are seeing but it doesn't match what I see in
>>> this test on the erc32.
>>>
>>> --joel
>>>
>>> On Fri, Sep 22, 2017 at 4:04 AM, xuelin.tian at qkmtech.com <
>>> xuelin.tian at qkmtech.com> wrote:
>>>
>>>> OK, no problem, thanks anyway.
>>>>
>>>> ------------------------------
>>>> Best wishes,
>>>> xuelin.tian at qkmtech.com
>>>>
>>>>
>>>> *From:* Sebastian Huber <sebastian.huber at embedded-brains.de>
>>>> *Date:* 2017-09-22 16:58
>>>> *To:* xuelin.tian at qkmtech.com; users at rtems.org
>>>> *Subject:* Re: pthread_getattr_np does not work
>>>> On 22/09/17 10:55, xuelin.tian at qkmtech.com wrote:
>>>>
>>>> > OK, I will try to do some fix on this function. And if Sherrill and
>>>> > you have time, please take some time on this. Thanks a lot.
>>>>
>>>> No, sorry. I have no time to fix this.
>>>>
>>>> --
>>>> Sebastian Huber, embedded brains GmbH
>>>>
>>>> Address : Dornierstr. 4
>>>> <https://maps.google.com/?q=Dornierstr.+4&entry=gmail&source=g>,
>>>> D-82178 Puchheim, Germany
>>>> Phone   : +49 89 189 47 41-16
>>>> Fax     : +49 89 189 47 41-09
>>>> E-Mail  : sebastian.huber at embedded-brains.de
>>>> PGP     : Public key available on request.
>>>>
>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/users
>>>>
>>>
>>> 自动判断 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语
>>> 丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语
>>> 冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语
>>> 北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语
>>> 茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语 自动选择 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语
>>> 俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语
>>> 加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语
>>> 拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语
>>> 斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语
>>> 班图语祖鲁语 有道翻译 百度翻译 必应翻译 谷歌翻译 谷歌翻译（国内） 翻译 朗读 复制 正在查询，请稍候…… 重试 朗读 复制 复制 朗读
>>> 复制 via 译
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170925/5648e90a/attachment-0002.html>