mktime() does not "normalize" struct tm argument
Hello team,
Recently I've been reviewing "strftime()" implementation from
"libs/libc/time/lib_strftime.c" and found interesting lines:
/* %s: The number of seconds since the Epoch, that is,
* since 1970-01-01 00:00:00 UTC.
* Hmmm... mktime argume is not 'const'.
*/
case 's':
{
len = snprintf(dest, chleft, "%ju",
(uintmax_t)mktime((FAR struct tm *)tm));
}
break;
This led me to the "mktime()" implementation and I found out that the NuttX
version of "mktime()" does not "normalize" struct tm argument. Is that a
designed behavior or this is a bug?
Best regards,
Petro
Re: usleep can't wake up incidentally in tickless mode
Hi Zou, Is there some way to identify that thread A didn't wake up and create some unity test to report and to analyze it? Maybe there is some very specific race condition that we never saw before. BR, Alan On 3/27/22, fft wrote: > Hi team, > > > I've been puzzled by a strange problem for a long time, when i use tickless > OS mode on stm32f405, usleep can't wake up incidentally. > > My config about tickless OS mode as shown below: > > > CONFIG_ARCH_HAVE_TICKLESS=y > CONFIG_SCHED_TICKLESS=y > # CONFIG_SCHED_TICKLESS_ALARM is not set > # CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP is not set > CONFIG_USEC_PER_TICK=10 > > # CONFIG_STM32_TICKLESS_SYSTICK is not set > > CONFIG_STM32_TICKLESS_TIMER=2 > CONFIG_STM32_TICKLESS_CHANNEL=1 > > > When use usleep(1000) in a pthread A, then thread A maybe sporadic sleep > dead and can't be wake up, the probability is about 1/10. > Moreover, when the problem happened, if i execute usleep 1 in NSH > terminus, then thread A will wakeup. Is my configuration incorrect? > > Does anyone else have the same problem? > > > Best regard > Zou
Re: usleep can't wake up incidentally in tickless mode
Zou, just a think that passed on my mind: try to enable the CONFIG_PRIORITY_INHERITANCE and let us know if the issue will happen again in this case. BR, Alan On 3/27/22, Alan Carvalho de Assis wrote: > Hi Zou, > > Is there some way to identify that thread A didn't wake up and create > some unity test to report and to analyze it? > > Maybe there is some very specific race condition that we never saw before. > > BR, > > Alan > > On 3/27/22, fft wrote: >> Hi team, >> >> >> I've been puzzled by a strange problem for a long time, when i use >> tickless >> OS mode on stm32f405, usleep can't wake up incidentally. >> >> My config about tickless OS mode as shown below: >> >> >> CONFIG_ARCH_HAVE_TICKLESS=y >> CONFIG_SCHED_TICKLESS=y >> # CONFIG_SCHED_TICKLESS_ALARM is not set >> # CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP is not set >> CONFIG_USEC_PER_TICK=10 >> >> # CONFIG_STM32_TICKLESS_SYSTICK is not set >> >> CONFIG_STM32_TICKLESS_TIMER=2 >> CONFIG_STM32_TICKLESS_CHANNEL=1 >> >> >> When use usleep(1000) in a pthread A, then thread A maybe sporadic sleep >> dead and can't be wake up, the probability is about 1/10. >> Moreover, when the problem happened, if i execute usleep 1 in NSH >> terminus, then thread A will wakeup. Is my configuration incorrect? >> >> Does anyone else have the same problem? >> >> >> Best regard >> Zou >
FAR usage education
Hi, I want to improve my knowledge about FAR usage in NuttX code. I've already read some initial information related to "Far memory" and "3-byte pointers to access extended memory spaces", but still lacking a practical experience with a real compiler and device use case. My main question is about FAR usage notation, because currently it seems to me very confusing. I assume that notation is very similar to "const", but do not have a way to prove it, so I'm asking for help from people that have more practical experience. So I will go with few examples: 1. FAR char *p; -- that is fully understood. Generate code to use a 3-bytes pointer to char. 2. FAR char **p; -- here where my understanding ends. Is this a 3-byte pointer to an array of traditional 2-byte pointers or traditional 2-byte pointer to an array of 3-byte pointers? Or even a 3-byte pointer to an array of 3-byte pointers? 3. The answer to this will come from answer on 2, but still: is "FAR char * FAR *p;" valid? I'm asking this because sometimes I modify common code that is equipped with "FAR" and want to be sure that my changes will not break things. Best regards, Petro
Re: FAR usage education
These are pretty standard C compiler concepts, although people used to working with pure 32-/64-bit CPUs may not have experience with them. They used to be very standard like in x86 real mode. Since they are standard concepts, you can probably get the more authoritative information by Googling, like https://www.google.com/search?q=far+near+C+qualifers . That brings up dozens of technical articles on near and far pointers. The first hit gives a pretty concise definition: https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86002268-209/section-66613.html The second hit, I think, answers all of you questions in the context of some Renesas CPU: http://tool-support.renesas.com/autoupdate/support/onlinehelp/csp/V4.01.00/CS+.chm/Compiler-CCRL.chm/Output/cd_EXP_LANG8.html There is a lot more info out there. On Sun, Mar 27, 2022 at 2:21 PM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > Hi, > > I want to improve my knowledge about FAR usage in NuttX code. I've already > read some initial information related to "Far memory" and "3-byte pointers > to access extended memory spaces", but still lacking a practical experience > with a real compiler and device use case. My main question is about FAR > usage notation, because currently it seems to me very confusing. I assume > that notation is very similar to "const", but do not have a way to prove > it, so I'm asking for help from people that have more practical experience. > So I will go with few examples: > > 1. FAR char *p; -- that is fully understood. Generate code to use a 3-bytes > pointer to char. > 2. FAR char **p; -- here where my understanding ends. Is this a 3-byte > pointer to an array of traditional 2-byte pointers or traditional 2-byte > pointer to an array of 3-byte pointers? Or even a 3-byte pointer to an > array of 3-byte pointers? > 3. The answer to this will come from answer on 2, but still: is "FAR char * > FAR *p;" valid? > > I'm asking this because sometimes I modify common code that is equipped > with "FAR" and want to be sure that my changes will not break things. > > Best regards, > Petro >
Re: FAR usage education
These are pretty standard C compiler concepts, although people used to > working with pure 32-/64-bit CPUs may not have experience with them. They > used to be very standard like in x86 real mode. > > ARM does not have near and far qualifier, but it does have some similar memory-related issues. The range of a subroutine call via a BL or branch, B, is only +/- 32Mb. That is usually large enough if you are executing out of a single, contiguous FLASH memory space. But if, for example, you are running an ELF module in RAM at, say, 0x2000 and calling into the OS in FLASH, at 0x, it is not enough range. There are no FAR pointers, but there is a long call compiler option(-mlong-calls) that is necessary to get the full 32-bit range of function calls and branches.
Re: FAR usage education
Thank you Gregory for your reply. I will definitely examine all the links
that you provided.
I'm familiar with ARM address access limitations and also with more exotic
ARC architecture where I first met .sdata and .sbss sections usage for data
that are located near GP. But as you already pointed out that is usually
handled by the compiler or by inserting a proper inline assembly code.
With FAR and NEAR I have more practical questions because those we are
handling manually in NuttX code. I will give you one example: In
libs/libc/dirent/lib_scandir.c there is "scandir" function that performs
next calls:
//-start code-
FAR struct dirent *dnew;
FAR struct dirent **list = NULL;
...
/* Grow the directory entry list, if required. */
if (cnt == listsize)
{
struct dirent **newlist;
...
newlist = lib_realloc(list, listsize * sizeof(*list));
...
list = newlist;
}
...
dnew = lib_malloc(dsize);
...
list[cnt] = dnew;
//-end code-
So when I review code like this I start asking myself "Is everything right
here?", because:
1. it seems to me that "lib_malloc" / "lib_realloc" return pointer to "FAR"
memory.
2. "newlist" is declared as "NEAR" pointer.
3. "list" -- seems to be a "NEAR" pointer to "FAR" data.
So either my assumption that "lib_realloc" / "lib_malloc" return "FAR"
pointers is wrong or we are missing "FAR struct dirent * FAR *list = NULL;"
and "struct dirent * FAR *newlist;".
I'm feeling like my example might look like a trivial case for a person who
is strongly familiar with the "FAR" / "NEAR" concept, so I will go and read
some papers before continuing this discussion :) I just want to describe
you were my intention comes from.
Best regards,
Petro
нд, 27 бер. 2022 р. о 22:42 Gregory Nutt пише:
> These are pretty standard C compiler concepts, although people used to
> > working with pure 32-/64-bit CPUs may not have experience with them.
> They
> > used to be very standard like in x86 real mode.
> >
> >
> ARM does not have near and far qualifier, but it does have some similar
> memory-related issues. The range of a subroutine call via a BL or branch,
> B, is only +/- 32Mb. That is usually large enough if you are executing
> out of a single, contiguous FLASH memory space. But if, for example, you
> are running an ELF module in RAM at, say, 0x2000 and calling into the
> OS in FLASH, at 0x, it is not enough range. There are no FAR
> pointers, but there is a long call compiler option(-mlong-calls) that is
> necessary to get the full 32-bit range of function calls and branches.
>
