Yes. Then pthread_create a thread to use that stack, let it run, and make sure pthread_getattr_np reports things correctly.
On Tue, Sep 26, 2017 at 6:52 AM, [email protected] < [email protected]> wrote: > You mean, I allocate an array of some size in another thread, and set the > pointer of this array as the stack address using pthread_attr_setstackaddr? > > > ------------------------------ > Best wishes, > [email protected] > > > *From:* Joel Sherrill <[email protected]> > *Date:* 2017-09-26 00:29 > *To:* [email protected] > *CC:* [email protected]; Sebastian Huber > <[email protected]> > *Subject:* Re: Re: pthread_getattr_np does not work > 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, [email protected] < > [email protected]> wrote: > >> OK, I will try to do this. >> >> ------------------------------ >> Best wishes, >> [email protected] >> >> >> *From:* Joel Sherrill <[email protected]> >> *Date:* 2017-09-24 21:32 >> *To:* xuelin.tian <[email protected]> >> *CC:* [email protected] <[email protected]>; Sebastian Huber >> <[email protected]> >> *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" <[email protected]> wrote: >> >>> So, is there a substitute function for this in RTEMS, without modifying >>> the source code? >>> >>> >>> ------------------ Original ------------------ >>> *From: * "Joel Sherrill"<[email protected]>; >>> *Date: * Sun, Sep 24, 2017 00:15 AM >>> *To: * "xuelin.tian"<[email protected]>; >>> *Cc: * "Sebastian Huber"<[email protected]>; " >>> [email protected]"<[email protected]>; >>> *Subject: * Re: Re: pthread_getattr_np does not work >>> >>> >>> >>> On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian <[email protected]> >>> 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"<[email protected]>; >>>> *Date: * Fri, Sep 22, 2017 10:15 PM >>>> *To: * "[email protected]"<[email protected]>; >>>> *Cc: * "Sebastian Huber"<[email protected]>; " >>>> [email protected]"<[email protected]>; >>>> *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, [email protected] < >>>> [email protected]> wrote: >>>> >>>>> OK, no problem, thanks anyway. >>>>> >>>>> ------------------------------ >>>>> Best wishes, >>>>> [email protected] >>>>> >>>>> >>>>> *From:* Sebastian Huber <[email protected]> >>>>> *Date:* 2017-09-22 16:58 >>>>> *To:* [email protected]; [email protected] >>>>> *Subject:* Re: pthread_getattr_np does not work >>>>> On 22/09/17 10:55, [email protected] 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 : [email protected] >>>>> PGP : Public key available on request. >>>>> >>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>>>> >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] >>>>> http://lists.rtems.org/mailman/listinfo/users >>>>> >>>> >>>> 自动判断 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语 >>>> 威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语 >>>> 印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语 >>>> 挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语 >>>> 叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语 自动选择 中文中文(简体)中文(香港) >>>> 中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语 >>>> 爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语 >>>> 卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语 >>>> 克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语 >>>> 乌克兰语乌都语乌兹别克语越南语班图语祖鲁语 有道翻译 百度翻译 必应翻译 谷歌翻译 谷歌翻译（国内） 翻译 朗读 复制 正在查询，请稍候…… >>>> 重试 朗读 复制 复制 朗读 复制 via 译 >>> >>> >>> >
_______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
