论坛

newlib,FreeRTOS,可重入,堆和相关问题

开始于 凝视 2020年2月6日
On Friday, 2020年2月7日 at 8:31:10 AM UTC-5, 凝视 wrote:
> After your considerations, why use a printf that uses heap? There are > other good implementations that don't use heap at all 和 so are > intrinsically thread-safe.
There's a list of alternate printf implementations on my web page you referenced. Other library functions like strtok use malloc 和 friends. Again, whatever you do, check the map 和 MAKE SURE you don't accidentally drag in non-thread-safe uses of library malloc family... Hope that helps, Best Regards, Dave
大卫·布朗 <david.brown@hesbynett.no> writes:
> The point is that because the compiler knows what malloc 和 free do - > they are specified in the standards - it can use that knowledge for > optimisation.
In this case it has accessed unallocated memory. I wonder if there is an exploit. Hmm.
On 07/02/2020 17:00, 保罗·鲁宾 wrote:
> 大卫·布朗 <david.brown@hesbynett.no> writes: >> The point is that because the compiler knows what malloc 和 free do - >> they are specified in the standards - it can use that knowledge for >> optimisation. > > In this case it has accessed unallocated memory. I wonder if there is > an exploit. Hmm. >
No, it hasn't accessed unallocated memory at all. It did not access anything. The compiler could see that either the malloc worked fine 和 the result would be the value 6, or the malloc would fail (and return 0) in which case the program would have undefined behaviour (accessing a null pointer). The compiler can assume that the programmer doesn't care what happens when executing undefined behaviour, 和 thus giving a result of 6 is perfectly acceptable there too. So the best code is simply to return 6 without any work at run time. Ironically, if I had checked the result of malloc() for a null pointer, it could not have made this optimisation!
大卫·布朗 <david.brown@hesbynett.no> writes:
> No, it hasn't accessed unallocated memory at all. It did not access > anything. The compiler could see that either the malloc worked fine > 和 the result would be the value 6,
It's a question of how the compiler implemented the compile-time execution. I hope that it didn't really allocate 6 bytes of memory at compile time, 和 then write past it. But it makes me wonder.
On 09/02/2020 04:42, 保罗·鲁宾 wrote:
> 大卫·布朗 <david.brown@hesbynett.no> writes: >> No, it hasn't accessed unallocated memory at all. It did not access >> anything. The compiler could see that either the malloc worked fine >> 和 the result would be the value 6, > > It's a question of how the compiler implemented the compile-time > execution. I hope that it didn't really allocate 6 bytes of memory at > compile time, 和 then write past it. But it makes me wonder. >
I'm lost here. Are you talking about the mistake I made in allocating 4 bytes, rather than 4 * sizeof(int) ? It makes no difference to the code generated when that is corrected, 和 I don't see where "6 bytes" comes from. The use of "malloc" in the source code bears no direct relation to having to allocate dynamic memory in the compiler. Compile-time execution means figuring out what the effect of the code is, 和 simulating it at compile time - it does /not/ mean executing it directly. And in particular, baring bugs in the compiler it does not mean executing undefined behaviour in the compiler - though it can mean ignoring it in the source code. (It would have been nice if the compiler had spotted my mistake 和 told me about it, however.)
On Thursday, 2020年2月6日 at 7:26:52 AM UTC-5, 凝视 wrote:
> [1] http://www.nadler.com/embedded/newlibAndFreeRTOS.html
Pozz, you mentioned you're trying to use ST's RubeMX. Be careful, extremely buggy support libraries 和 examples!! Latest unbelievable foolishness here: //community.st.com/s/question/0D50X0000CBmXufSQF/newlibmalloc-locking-mechanism-to-be-threadsafe Avoid the ST suggestions!!! Aaaaarrrrggggg.....