I tried it, and it worked.
But, there is another problem that I need to free this array (or buffer) by my
self. This bunch of buffer can not be freed by calling pthread_attr_destroy.
Maybe this is a little inconvenient.
Any suggestion on this?
Best wishes,
xuelin.t...@qkmtech.com
From: Joel Sherrill
Date: 2017-09-26 23:16
To: xuelin.t...@qkmtech.com
CC: users@rtems.org; Sebastian Huber
Subject: Re: Re: pthread_getattr_np does not work
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, xuelin.t...@qkmtech.com
<xuelin.t...@qkmtech.com> 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,
xuelin.t...@qkmtech.com
From: Joel Sherrill
Date: 2017-09-26 00:29
To: xuelin.t...@qkmtech.com
CC: users@rtems.org; Sebastian Huber
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, xuelin.t...@qkmtech.com
<xuelin.t...@qkmtech.com> wrote:
OK, I will try to do this.
Best wishes,
xuelin.t...@qkmtech.com
From: Joel Sherrill
Date: 2017-09-24 21:32
To: xuelin.tian
CC: rtems-us...@rtems.org; Sebastian Huber
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.t...@qkmtech.com> wrote:
So, is there a substitute function for this in RTEMS, without modifying the
source code?
------------------ Original ------------------
From: "Joel Sherrill"<j...@rtems.org>;
Date: Sun, Sep 24, 2017 00:15 AM
To: "xuelin.tian"<xuelin.t...@qkmtech.com>;
Cc: "Sebastian Huber"<sebastian.hu...@embedded-brains.de>;
"users@rtems.org"<users@rtems.org>;
Subject: Re: Re: pthread_getattr_np does not work
On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian <xuelin.t...@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"<j...@rtems.org>;
Date: Fri, Sep 22, 2017 10:15 PM
To: "xuelin.t...@qkmtech.com"<xuelin.t...@qkmtech.com>;
Cc: "Sebastian Huber"<sebastian.hu...@embedded-brains.de>;
"users@rtems.org"<users@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.t...@qkmtech.com
<xuelin.t...@qkmtech.com> wrote:
OK, no problem, thanks anyway.
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-09-22 16:58
To: xuelin.t...@qkmtech.com; users@rtems.org
Subject: Re: pthread_getattr_np does not work
On 22/09/17 10:55, xuelin.t...@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, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
自动判断
中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语
自动选择
中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语
有道翻译 百度翻译 必应翻译 谷歌翻译 谷歌翻译（国内） 翻译 朗读 复制 正在查询，请稍候…… 重试 朗读 复制 复制 朗读 复制 via 译
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
