You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/07/05 09:09:02 UTC
[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #1369: arch: Initialize idle thread stack information
xiaoxiang781216 opened a new pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369
## Summary
arch layer normally forget to initialize the idle stack, which isn't a critical issue before because it only affect the stack coloring. But the uninitialized stack info will crash the system with the new TLS implementation:
https://github.com/apache/incubator-nuttx/issues/986
so let's fix it.
## Impact
## Testing
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-692614601
@xiaoxiang781216 Please fix the CI fail. https://github.com/apache/incubator-nuttx/pull/1369/checks?check_run_id=1116310069
If you change anything else PLEASE do not force push. We can squash after review and force push.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487415276
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r456813106
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@davids5 do you have any suggestion to fix the issue I mentioned? If not, it's impossible to implement the auto size which mean the margin can't be avoid.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488176858
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@xiaoxiang781216 Does this
```
diff --git a/arch/arm/src/common/arm_usestack.c b/arch/arm/src/common/arm_usestack.c
index b59b3baf39..6cef37b595 100644
--- a/arch/arm/src/common/arm_usestack.c
+++ b/arch/arm/src/common/arm_usestack.c
@@ -153,11 +153,54 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
- * because the code is running on the idle thead now.
+ * because the code is running on the idle thread now.
+ *
+ * So let's see what we can do
*/
+
+ /* Some address on stack */
+
+ volatile uint32_t marker1;
+
+ /* Use register based variables */
+
+ register volatile uint32_t *sp;
+ register uint32_t size;
+
+ /* Another address on stack */
+
+ volatile uint32_t marker2;
+
+ /* Assume we can not get a better value. */
+
+ size = tcb->adj_stack_size - STACK_MARGIN_IDLE;
+
+ /* point to the lower or the 2 address on the stack */
+
+ sp = (&marker1 > &marker2) ? &marker2 : &marker1;
+
+
+ /* Do a sanity check,
+ * a) markers 1 and 2 are not the same
+ * b) markers 1 and 2 are next each other (nothing in between)
+ * c) sp is in this stack's extent
+ */
+
+ if (&marker1 != &marker2 &&
+ sizeof(uint32_t) == (&marker1 > &marker2 ?
+ (uint8_t *)&marker1 - (uint8_t *)&marker2 :
+ (uint8_t *)&marker2 - (uint8_t *)&marker1) &&
+ (sp > (volatile uint32_t *)stack &&
+ sp < (volatile uint32_t *) tcb->adj_stack_ptr) &&
+ (uintptr_t)sp - (uintptr_t)stack > size)
+ {
+ /* Use the batter value */
+
+ size = (uintptr_t) sp - (uintptr_t)stack;
+ }
arm_stack_color((FAR void *)((uintptr_t)tcb->adj_stack_ptr -
- tcb->adj_stack_size), tcb->adj_stack_size - STACK_MARGIN_IDLE);
+ tcb->adj_stack_size), size);
}
else
{
```
address all you concerns.
Full Stack colorizing
119 bytes better
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-656265711
@Ouss4 could you review the PR which fix the potential panic after #986?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-693425016
@xiaoxiang781216 Thank you for reminding me, I was waiting for CI to finish and forgot to check back.
@btashton is there a way to get CI completion notifications?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449886721
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
The call chain is fixed:
__start(2)->nx_start(2)->up_initial_state(1)->up_use_stack(2)->arm_stack_color(3)
The number of local variables declared by each function is marked in the parenthesis.
The total number is 10(40 bytes) which is much less than 128 bytes.
Yes, it isn't 100% safe in the theory, only assembler code like go_nx_start can give 100% guarantee. If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449883427
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
The margin avoid the stack coloring to corrupt the running context. We can't colorize the whole idle stack because we are running on the idle thread during the stystem initialization.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449883427
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
The margin avoid the stack coloring to corrupt the current calling context. We can't colorize the whole idle stack because we are running on the idle thread during the stystem initialization.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487427238
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452894490
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449886721
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
The call chain is fixed:
```
__start(2)->nx_start(2)->up_initial_state(1)->up_use_stack(2)->arm_stack_color(3)
```
The number of local variables declared by each function is marked in the parenthesis.
The total number is 10(40 bytes) which is much less than 128 bytes. Since the idle thread stack likely will be consumed at least 384 bytes, we can even change IDLETHREAD_STACKMARGIN to 384 bytes without losing any information.
Yes, it isn't 100% safe in the theory, only assembler code like go_nx_start can give 100% guarantee. If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452894490
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487427238
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488623318
##########
File path: arch/avr/src/avr/up_usestack.c
##########
@@ -119,7 +111,10 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
*/
#ifdef CONFIG_STACK_COLORATION
- memset(tcb->stack_alloc_ptr, STACK_COLOR, stack_size);
Review comment:
Because it would have over written the stack the code is executing on and crashed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] masayuki2009 edited a comment on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
masayuki2009 edited a comment on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-666833589
@xiaoxiang781216
Fixed in https://github.com/apache/incubator-nuttx/pull/1482
```
arch/arm/src/lc823450/lc823450_start.c:259:14: error: Mixed case identifier found
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487020892
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487162566
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487427238
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487020892
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488198031
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@xiaoxiang781216 - I sent you a PR on your PR. https://github.com/xiaoxiang781216/incubator-nuttx/pulls
As a side note. I think would leave the the asm code in the xxx_start files, with a #if 0.
The reasoning is that: By moving the coloring many steps in from the startup code, we are would be removing a tool that may be needed way before the IDLE task is initialized. I.E. all the driver startup code, etc.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488063228
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@davids5 please give your comment.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487430617
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-693427214
There's a "merge when CI passes" feature that can be enabled. Sadly it appears that it is not expose via asf.yaml. Maybe we can ask INFRA to do it but they seem to really take their time.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487427238
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487430617
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487423252
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487020892
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. especially, if we enable some advance feature(e.g. AddressSanitizer,
Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
> If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my reply again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question and give a workable solution to handle this case?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487065598
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-656265711
@Ouss4 could you review the PR which fix the potential panic after #986
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449880462
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I recall an issue with eabi were there needs to be alignment on 8. What is IDLETHREAD_STACKMARGIN being used for? should be CONFIG settable?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452803621
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Why not add the "is this my stack test to arm_stack_color" and do it the right way?
So you prefer get the current stack pointer either from a local variable or xxx_getsp, but as I said before we still need some margin here, which value do you think reasonable?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488111625
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I am a working on it ...
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449884524
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
eeh that is why the asm code was used to do the init it. Originally we took the address of the last var on the stack in the called routine and wrote up to. This margin think could bite us.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487415276
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> Well the assembly code works. and it is not portable.
>
> I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
Then how do I handle this with your method? You need give a solution, right?
> **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> Here is how I was looking at it. 1) I Draw a picture of the stack frame
> [ ]
> [ ]
> [ ]
> [ ]<---At the function
> [ marker1]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker2 ]
> [ ] <- the allocation
>
> if the compiler messes with you and it looks like this, does not matter.
>
> [ marker2]
> [ ]
> [ what is here or not does not matter ]
> [ ]
> [ marker1 ]
> [ ] <- the allocation
>
> safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
Then do you think it's the right thing to memset "[ ] <- the allocation"?!
The allocation region may contain:
1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
2. The compiler may add more temporary variables as needed and put to here
3. ASAN or SSP may add the special mark to here too
Please give a solution before I can use your method.
> DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
"it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statment is right.
> Set the start address and write from bottom up or top down from or to `safe`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488423953
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@davids5 I understand your propose, but it can't handle the arch which call memset directly. Anyway, I will remove the colorize related change from this patch. Let's your upcoming PR fix it.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488642828
##########
File path: arch/avr/src/avr/up_usestack.c
##########
@@ -119,7 +111,10 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
*/
#ifdef CONFIG_STACK_COLORATION
- memset(tcb->stack_alloc_ptr, STACK_COLOR, stack_size);
Review comment:
I was assuming up_usestack.c was called with the IDEL stack before if it was not I am wrong.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] jerpelea commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
jerpelea commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-666983240
LGTM
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449886721
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
The call chain is fixed:
```
__start(2)->nx_start(2)->up_initial_state(1)->up_use_stack(2)->arm_stack_color(3)
```
The number of local variables declared by each function is marked in the parenthesis.
The total number is 10(40 bytes) which is much less than 128 bytes.
Yes, it isn't 100% safe in the theory, only assembler code like go_nx_start can give 100% guarantee. If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452894490
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488622521
##########
File path: arch/risc-v/src/common/riscv_usestack.c
##########
@@ -165,9 +157,12 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
* water marks.
*/
- up_stack_color((FAR void *)((uintptr_t)tcb->stack_alloc_ptr +
Review comment:
Same question.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-692673851
@xiaoxiang781216 did you get this one?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-666871676
@masayuki2009 thanks, the style check can pass now.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-680953969
Does anyone can look this patch? Many chip will hit panic without this patch now if CONFIG_RTC=y.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r449883427
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
The margin avoid the stack coloring to corrupt the current context. We can't colorize the whole idle stack because we are running on the idle thread during the stystem initialization.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452886847
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@xiaoxiang781216 I am thinking along theses lines:
Auto size it.
If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
If you write from stack botom to current lowest marker on the stack.
```
int arm_stack_color(stack, size)
{
volatile uint32_t marker1;
register real vars...;
uint32_t nos;
volatile uint32_t marker2;
if (check stack is is mine)
{
/* make no assumptions */
nos = min( &marker2, &marker1);
size = nos - stack;
}
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487430617
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
Let me give you an example:
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_checkstack.c#L97
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/avr/up_createstack.c#L198
https://github.com/apache/incubator-nuttx/blob/master/arch/avr/src/common/up_internal.h#L69
Please tell me what's wrong avr colorize the stack with memset and how your approach handle this case? I aks the same question two months ago, this is a key reason why I don't take your approach initially. Here is a capture:
Could you answer my question?
>
> I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
The system is already in broken state now, all arch which forget to set idle thread info can't boot into shell if they match:
1.Enable CONFIG_RTC
2.Enable CONFIG_LIBC_LOCALTIME
We found this issue on simulator two months ago, the problem is still there, no any progress!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488622291
##########
File path: arch/sim/src/sim/up_usestack.c
##########
@@ -136,9 +136,12 @@ int up_use_stack(FAR struct tcb_s *tcb, FAR void *stack, size_t stack_size)
* water marks.
*/
- up_stack_color((FAR void *)((uintptr_t)tcb->stack_alloc_ptr +
- sizeof(struct tls_info_s)),
- tcb->adj_stack_size - sizeof(struct tls_info_s));
+ if (tcb->pid != 0)
Review comment:
Are you sure? we use simulator daily, the stack colorize is a key feature to estimate the stack usage:
```
[ 0.000000] TAPDEV: ioctl failed (can't add interface tap0 to bridge nuttx0): 1
[ 0.000000] NuttX 9.1.0 2ed7902240 Sep 15 2020 05:13:23 sim sim
uorb [7:100]
NuttShell (NSH) NuttX-9.1.0
nsh> ps
PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
0 0 0 FIFO Kthread N-- Ready 00000000 002048 001720 83.9%! Idle Task
1 1 224 FIFO Kthread --- Waiting Signal 00000000 008208 001136 13.8% hpwork
2 1 100 FIFO Kthread --- Waiting Signal 00000000 015376 001776 11.5% lpwork
3 1 100 FIFO Task --- Running 00000000 030736 003724 12.1% init
4 4 100 FIFO Task --- Waiting Semaphore 00000010 008176 001440 17.6% Telnet daemon 0xf378a200
5 4 100 FIFO Task --- Waiting Semaphore 00000010 008176 001440 17.6% Telnet daemon 0xf378c7f0
8 1 80 FIFO pthread --- Waiting Semaphore 00000000 008224 002192 26.6% netinit 0x0
nsh>
```
Do you see USED and FILLED column?
##########
File path: arch/avr/src/avr/up_usestack.c
##########
@@ -119,7 +111,10 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
*/
#ifdef CONFIG_STACK_COLORATION
- memset(tcb->stack_alloc_ptr, STACK_COLOR, stack_size);
Review comment:
Why you have this assumption?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488539884
##########
File path: arch/risc-v/src/common/riscv_usestack.c
##########
@@ -165,9 +157,12 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
* water marks.
*/
- up_stack_color((FAR void *)((uintptr_t)tcb->stack_alloc_ptr +
Review comment:
Another one never used
##########
File path: arch/avr/src/avr/up_usestack.c
##########
@@ -119,7 +111,10 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
*/
#ifdef CONFIG_STACK_COLORATION
- memset(tcb->stack_alloc_ptr, STACK_COLOR, stack_size);
Review comment:
I would say it is safe to assume that CONFIG_STACK_COLORATION has never been turned on for AVR
##########
File path: arch/sim/src/sim/up_usestack.c
##########
@@ -136,9 +136,12 @@ int up_use_stack(FAR struct tcb_s *tcb, FAR void *stack, size_t stack_size)
* water marks.
*/
- up_stack_color((FAR void *)((uintptr_t)tcb->stack_alloc_ptr +
- sizeof(struct tls_info_s)),
- tcb->adj_stack_size - sizeof(struct tls_info_s));
+ if (tcb->pid != 0)
Review comment:
CONFIG_STACK_COLORATION was never used
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487065598
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Well the assembly code works. and it is not portable.
I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
**Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
Here is how I was looking at it. 1) I Draw a picture of the stack frame
[ ]
[ ]
[ ]
[ ]<---At the function
[ marker1]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker2 ]
[ ] <- the allocation
if the compiler messes with you and it looks like this, does not matter.
[ marker2]
[ ]
[ what is here or not does not matter ]
[ ]
[ marker1 ]
[ ] <- the allocation
safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
Set the start address and write from bottom up or top down from or to `safe`.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] masayuki2009 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
masayuki2009 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-666833589
Fixed in https://github.com/apache/incubator-nuttx/pull/1482
```
arch/arm/src/lc823450/lc823450_start.c:259:14: error: Mixed case identifier found
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previous.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452894490
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452776246
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
Why not add the "is this my stack test to arm_stack_color" and do it the right way?
This comes to mind...
```
The Enemies
===========
No Short Cuts
-------------
o Doing things the easy way instead of the correct way.
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452894490
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488636352
##########
File path: arch/avr/src/avr/up_usestack.c
##########
@@ -119,7 +111,10 @@ int up_use_stack(struct tcb_s *tcb, void *stack, size_t stack_size)
*/
#ifdef CONFIG_STACK_COLORATION
- memset(tcb->stack_alloc_ptr, STACK_COLOR, stack_size);
Review comment:
Could you point out where will overwrite the stack?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487423252
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > Well the assembly code works. and it is not portable.
> > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
>
> Then how do I handle this with your method? You need give a solution, right?
>
> > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
>
> I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
>
> > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > [ ]
> > [ ]
> > [ ]
> > [ ]<---At the function
> > [ marker1]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker2 ]
> > [ ] <- the allocation
> > if the compiler messes with you and it looks like this, does not matter.
> > [ marker2]
> > [ ]
> > [ what is here or not does not matter ]
> > [ ]
> > [ marker1 ]
> > [ ] <- the allocation
> > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
>
> Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> The allocation region may contain:
>
> 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> 2. The compiler may add more temporary variables as needed and put to here
> 3. ASAN or SSP may add the special mark to here too
>
> Please give a solution before I can use your method.
I would make it a simple function and make it work. I would test it on different archs,
If you are not sure the the compiler will do. Write it in assembly .
>
> > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
>
> First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
This is the original code
https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
It does the correct thing.
> "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
The pattern is STACK_COLOR = 0xdeadbeef
This is what is used to check penetration and it MUST match. Or you will break the detection,.
> > Set the start address and write from bottom up or top down from or to `safe`.
Set the start address and write from bottom up to safe
or
write from top down from `safe` to the base.
I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
If you post the code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452894490
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> @xiaoxiang781216 I am thinking along theses lines:
>
> Auto size it.
>
> If the passed pointer is on the current stack. I guess (pid == 0) would work, but generic would be better;
>
> If you write from stack botom to current lowest marker on the stack.
>
> ```
> int arm_stack_color(stack, size)
> {
> volatile uint32_t marker1;
> register real vars...;
> uint32_t nos;
> volatile uint32_t marker2;
> if (check stack is is mine)
> {
> /* make no assumptions */
> nos = min( &marker2, &marker1);
> size = nos - stack;
> }
> ```
Two issues here:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset.
2.The code isn't portable at least in the theroy, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487427827
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
I may not understand what you are saying, I may be busy. I am not ignoring you or making a negative statement.
I am letting you know you will break working code if make the change across the all the ARCHs of the system. We have had that happen before.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487427238
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > > Well the assembly code works. and it is not portable.
> > > I did not consider e.g. AddressSanitizer, Stack Smashing Protector. - So you may be correct this may not work.
> >
> >
> > Then how do I handle this with your method? You need give a solution, right?
> > > **Please Note: Fill the stack ONLY with the fill value as defined from before or you will break all the monitors.**
> >
> >
> > I can't understand what you mean. I don't change the fill value(all value same as before) in this patch. If I am wrong, please point the code location I will correct them.
> > > Here is how I was looking at it. 1) I Draw a picture of the stack frame
> > > [ ]
> > > [ ]
> > > [ ]
> > > [ ]<---At the function
> > > [ marker1]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker2 ]
> > > [ ] <- the allocation
> > > if the compiler messes with you and it looks like this, does not matter.
> > > [ marker2]
> > > [ ]
> > > [ what is here or not does not matter ]
> > > [ ]
> > > [ marker1 ]
> > > [ ] <- the allocation
> > > safe = min of (&marker2, &marker1) word gets you the lowest point on the stack you can write to,
> >
> >
> > Then do you think it's the right thing to memset "[ ] <- the allocation"?!
> > The allocation region may contain:
> >
> > 1. The variables we defined between marker1 and marker2, but the compiler free to move them to here
> > 2. The compiler may add more temporary variables as needed and put to here
> > 3. ASAN or SSP may add the special mark to here too
> >
> > Please give a solution before I can use your method.
>
> I would make it a simple function and make it work. I would test it on different archs,
>
As I said before, it work with the current compiler and option, doesn't mean it work in the furture. So your propose isn't bettter than what PR done.
> If you are not sure the the compiler will do. Write it in assembly .
>
Yes, that's why I ask you two months ago, let me quote it here to remember you:
If you like go_nx_start approach, I can keep go_nx_start as before and let up_use_stack skip to colorize the idle thread stack. But, I don't have time to implement go_nx_start for each SoC.
But you ignore my question again.
> > > DO NOT Use MEMSET! (it will not write the correct pattern, and you already know the call it a problem) Use a for() with the appropriate sized type
> >
> >
> > First, the original code use memset, not my patch. Second, why not use memset? the orignial code work well.
>
> This is the original code
> https://github.com/PX4/NuttX/blob/ec20f2e6c5cc35b2b9bbe942dea55eabb81297b6/arch/arm/src/stm32/stm32_start.c#L225-L256
>
> It does the correct thing.
>
> > "it will not write the correct pattern", could you explain the reason? Sorry, I don't think this statement is right.
>
> The pattern is STACK_COLOR = 0xdeadbeef
>
> This is what is used to check penetration and it MUST match. Or you will break the detection,.
I kindly point out memset serveral time, do you look at the realated code before you make any negative statement? On the other arch, STACK_COLOR equals 0xaa!!! So please review my patch fully, please.
>
> > > Set the start address and write from bottom up or top down from or to `safe`.
>
> Set the start address and write from bottom up to safe
> or
> write from top down from `safe` to the base.
>
> I feel we saying the same thing over and over again and not making progress. Have you looked at the code generated and determined this will not work or is that your opinion?
>
> If you post the generated code that proves you can not do it across the permutations of ARCH, ASAN or SSP that will prove it does not work.
>
> You have to realize that there is also a risk with the #define approach, that cause a problem when the call level get pushed deeper.
Yes, both approach aren't perfect, that's why I don't accept your propose. Actually, I initially take your propose but find that many arch call memset to colorize the stack which make your propose is impossible to complete.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-680954121
Does anyone can look this patch? Many chip will hit panic without this patch now if CONFIG_RTC=y.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] Ouss4 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
Ouss4 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452536120
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> This margin think could bite us.
@davids5 wasn't a margin already there: `"\tmov r1, r1, lsr #2\n" /* R1 = nwords = nbytes >> 2 */`
With the latest change the margin is the same as the above.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 merged pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 merged pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452756558
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@Ouss4
> "\tmov r1, r1, lsr #2\n" /* R1 = nwords = nbytes >> 2 */
That is the the stack size in bytes being converted to words then aligned on a word boundary.
The code then jumps with a completely "colored" stack to nx_start
The PR will not do the same thing. It is coloring the stack it is running on. When the stack to be colored is the stack you are running on you can take the address of a last stack var (defined volatile) in the called routine and and treat that as the end of the write. The oversize guess will not show true penetration. It will show running off the end, but you can do that with a guard block.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memroy layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
davids5 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487065598
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer 3 weeks ago, but you ignore it silently. So I have copy my response here again, please you give your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#issuecomment-693423036
@davids5 could you merge this path if you don't have more concern.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more temporary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen with the memory layout behind the scene if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r487147789
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> > ping again, @davids5 this patch is pending for more than two months, could you answer my question a little bit timely?
>
> What I suggested will work, you understanding it may not. This will safely get the the margin. Why don't you try it,
Yes, I want to try, but it can't work and I have give my answer two months ago, but you ignore it silently. So I have to copy my response here again, please you give me your comment one by one, so I can try with your new propose:
1.Many arch don't have xxx_stack_color, but call memset directly, then we have to add some margin again for memset. Here is an example:
```
#ifdef CONFIG_STACK_COLORATION
if (tcb->pid == 0)
{
/* The whole idle thread stack can't be colored here
* because the code is running on the idle thead now.
*/
memset(tcb->stack_alloc_ptr, 0xaa, stack_size - STACK_MARGIN_IDLE);
}
else
{
memset(tcb->stack_alloc_ptr, 0xaa, stack_size);
}
#endif
```
Pleaase tell me how can I measure memset stack consumption with your method? Do you want me to add the marker into memset?
2.The code isn't portable at least in the theory, because the compiler permit to move "register real vars...;" out of the marker or add more tempary variables as need. Especially, if we enable some advance feature(e.g. AddressSanitizer, Stack Smashing Protector). Please read the related document to understand what will happen behind the scene with the memory layout if you aren't fimilar with these technique.
Actually before I made the change in this way, I have consider your propose carefully and give up finally due the reason I mention previously.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r452771350
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
> When the stack to be colored is the stack you are running on you can take the address of a last stack var (defined volatile) in the called routine and and treat that as the end of the write.
We need add some margin here, because the called functions(arm_stack_color) still consume some stack space.
> The oversize guess will not show true penetration. It will show running off the end, but you can do that with a guard block.
Any value smaller than the final stack consumption is a good margin candidate, 1/4 stack size used in new code is a reasonable value.
And you can see only a few chip(13) implement the idle stack coloring, but this patch make all chipset get this feature.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1369: arch: Initialize idle thread stack information
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on a change in pull request #1369:
URL: https://github.com/apache/incubator-nuttx/pull/1369#discussion_r488423953
##########
File path: arch/arm/src/arm/arm_initialstate.c
##########
@@ -52,13 +52,7 @@
* Pre-processor Definitions
****************************************************************************/
-/****************************************************************************
- * Private Data
- ****************************************************************************/
-
-/****************************************************************************
- * Private Functions
- ****************************************************************************/
+#define IDLETHREAD_STACKMARGIN 128
Review comment:
@davids5 I understand your propose, but it can't handle the arch which call memset directly. Anyway, I will remove the colorize related change from this patch. Let's your upcoming PR fix it. Ok, please review the update.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org