ltp_clone alignment issues.

LTP Carmelo AMOROSO 5 participants 20 messages Sep 27, 2010 – Nov 24, 2010 Library code

Share & tools

Carmelo AMOROSO

author

2010-09-27 13:34 UTC #0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.

Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).

So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.

On my SH4 arch, the stack must be 4byte aligned (as in ARM).

Please, find attached a patch against master branch

Best regards,
Carmelo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkygnU0ACgkQoRq/3BrK1s+GugCgrrCDWRWknR36qdOFv6Qzg4Kl tEAAn1lRyS/5RL2ymbrX4A3q+7L3w/Gs
=yBmF
-----END PGP SIGNATURE-----

From 9393da0a1a6959cc5d25f73be63baf8c3fae8762 Mon Sep 17 00:00:00 2001
From: Carmelo Amoroso <[email protected]>
Date: Mon, 27 Sep 2010 13:00:06 +0000
Subject: [PATCH] lib: Fix ltp_clone wrapper stack argument for all architectures

For all the architectures that have stack that grows downwards, the stack argument passed to the clone function points to the topmost address of the memory space set up for the child stack. So it is not correct to move the stack down. The ABI guarantees that the function has to create it's own stack frame.

Nevertheless, on some architectures that do not accept unaligned stack, it causes the process to be killed by the kernel with a SIGBUS. On architectures that safely handle unaligned stack, we are actually reserving one byte less.

Signed-off-by Carmelo Amoroso <[email protected]>

---
 lib/cloner.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

lib/cloner.c +3 -6

index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void *arg), void *arg,
 	ret = clone(fn, stack, clone_flags, arg);
 #elif defined(__ia64__)
 	ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL, NULL);
-#elif defined(__arm__)
+#else
 	/*
-	 * Stack size should be a multiple of 32 bit words
-	 * & stack limit must be aligned to a 32 bit boundary
+	 * For archs where stack grows downwards, stack points to the topmost address
+	 * of the memory space set up for the child stack.
 	 */
 	ret = clone(fn, (stack ? stack + stack_size : NULL),
 			clone_flags, arg);
-#else
-	ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
-			clone_flags, arg);
 #endif
 
 	return ret;

Signature · 1 line

1.7.1

_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Carmelo AMOROSO

author

2010-09-29 13:35 UTC #1 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 17 lines · Carmelo AMOROSO

Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.

Quoted 6 lines

On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch
Best regards,
Carmelo

Hi,
any feedback on this ?

Cheers,
Carmelo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjQHAACgkQoRq/3BrK1s9mRQCfYVc9ePJRwf5hd6NRvjtjHsLO sxYAoMj83bu0I4cvU+iEUpH4iXGuBJTD
=s2GZ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Ltp-list mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Hannu Heikkinen

2010-09-30 10:33 UTC #2 lore raw

Quoted 25 lines · ext Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 21 lines · Carmelo AMOROSO
Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.
On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch

Quoted 10 lines

Quoted 2 lines
Best regards,
Carmelo
Hi,
any feedback on this ?
Cheers,
Carmelo
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

Signed-off-by Carmelo Amoroso <[email protected]>

---
 lib/cloner.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

lib/cloner.c +0 -0

index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void

*arg), void *arg,

        ret = clone(fn, stack, clone_flags, arg);

#elif defined(__ia64__)
ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
NULL);
-#elif defined(__arm__)
+#else

        /*
-        * Stack size should be a multiple of 32 bit words
-        * & stack limit must be aligned to a 32 bit boundary
+        * For archs where stack grows downwards, stack points to the topmost
address
+        * of the memory space set up for the child stack.
         */
        ret = clone(fn, (stack ? stack + stack_size : NULL),
                        clone_flags, arg);

-#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
- clone_flags, arg);
#endif

        return ret;

Signature · 22 lines

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Hi,

Acked-by Hannu Heikkinen <[email protected]>

Br,
Hannu

-- 
Hannu Heikkinen
http://www.nixu.com

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Carmelo AMOROSO

author

2010-09-30 10:43 UTC #3 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 74 lines · Hannu Heikkinen

Quoted 8 lines · ext Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Carmelo AMOROSO
Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Quoted 17 lines
Quoted 17 lines
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.
On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch
Quoted 10 lines
Quoted 2 lines
Best regards,
Carmelo
Hi,
any feedback on this ?
Cheers,
Carmelo
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Signed-off-by Carmelo Amoroso <[email protected]>
---
lib/cloner.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
lib/cloner.c +2 -3
index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void
 *arg), void *arg,
 ret = clone(fn, stack, clone_flags, arg);
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
-#elif defined(__arm__)
+#else
 /*
- * Stack size should be a multiple of 32 bit words
- * & stack limit must be aligned to a 32 bit boundary
+ * For archs where stack grows downwards, stack points to the topmost
address
+ * of the memory space set up for the child stack. */
ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg);
-#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
- clone_flags, arg);
#endif
return ret;
-- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi,

Quoted 9 lines

Acked-by Hannu Heikkinen <[email protected]>
Br,
Hannu
--
Hannu Heikkinen
http://www.nixu.com

Thanks, Hannu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkykaaAACgkQoRq/3BrK1s9XQQCgqFuIf0UtZVE2cIY07ZY+6PrN pmwAnRP5T4nCrFDwre+9VEwJ7WB6r0em
=w2Z8
-----END PGP SIGNATURE-----

Hannu Heikkinen

2010-10-01 04:06 UTC #4 lore raw

Quoted 93 lines · Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 74 lines · Hannu Heikkinen
Quoted 8 lines · ext Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Carmelo AMOROSO
Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Quoted 17 lines
Quoted 17 lines
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.
On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch
Quoted 10 lines
Quoted 2 lines
Best regards,
Carmelo
Hi,
any feedback on this ?
Cheers,
Carmelo
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Signed-off-by Carmelo Amoroso <[email protected]>
---
lib/cloner.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
lib/cloner.c +2 -3
index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void
 *arg), void *arg,
 ret = clone(fn, stack, clone_flags, arg);
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
-#elif defined(__arm__)
+#else
 /*
- * Stack size should be a multiple of 32 bit words
- * & stack limit must be aligned to a 32 bit boundary
+ * For archs where stack grows downwards, stack points to the topmost
address
+ * of the memory space set up for the child stack. */
ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg);
-#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
- clone_flags, arg);
#endif
return ret;
-- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi,
Quoted 9 lines
Acked-by Hannu Heikkinen <[email protected]>
Br,
Hannu
--
Hannu Heikkinen
http://www.nixu.com
Thanks, Hannu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

Quoted 4 lines

iEYEARECAAYFAkykaaAACgkQoRq/3BrK1s9XQQCgqFuIf0UtZVE2cIY07ZY+6PrN pmwAnRP5T4nCrFDwre+9VEwJ7WB6r0em
=w2Z8
-----END PGP SIGNATURE-----

Hi,

I was thinking your patch once again, and I think it would be wiser if we would have something like:

--- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.000000000
+0300
+++ lib/cloner.c 2010-09-03 14:48:20.000000000 +0300
@@ -43,6 +43,16 @@

                pid_t *parent_tid, void *tls, pid_t *child_tid);

#endif

+/*
+ * Most arch really want to have stack aligned to some sane boundary.
+ */
+#ifdef __arm__
+#define ALIGN_STACK(stack) \
+ ((void *)(((unsigned long)stack) & ~((sizeof(void *)) - 1)))
+#else
+#define ALIGN_STACK(stack) (stack)
+#endif
+
/***********************************************************************
* ltp_clone: wrapper for clone to hide the architecture dependencies.
* 1. hppa takes bottom of stack and no stacksize (stack grows up)
@@ -60,7 +70,7 @@
#elif defined(__ia64__)
ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
NULL);
#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
+ ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL),

                        clone_flags, arg);

#endif

The above patch iis in use in our ARM based LTP test suite. Note that -1 is needed for not clobbering eg possibly malloced area after child stack. Could u please change that prev patch a bit, for ensuring that child stack is in proper size etc. Above patch is not sufficient, because ALIGN_STACK in that is only used for arm archs.

br,
Hannu

Carmelo AMOROSO

author

2010-10-04 13:05 UTC #5 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 125 lines · Hannu Heikkinen

On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
Quoted 75 lines · Hannu Heikkinen
Quoted 8 lines · ext Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Carmelo AMOROSO
Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Quoted 17 lines
Quoted 17 lines
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.
On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch
Quoted 10 lines
Quoted 2 lines
Best regards,
Carmelo
Hi,
any feedback on this ?
Cheers,
Carmelo
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Signed-off-by Carmelo Amoroso <[email protected]>
---
lib/cloner.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
lib/cloner.c +2 -3
index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void
 *arg), void *arg,
 ret = clone(fn, stack, clone_flags, arg);
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
-#elif defined(__arm__)
+#else
 /*
- * Stack size should be a multiple of 32 bit words
- * & stack limit must be aligned to a 32 bit boundary
+ * For archs where stack grows downwards, stack points to the topmost
address
+ * of the memory space set up for the child stack. */
ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg);
-#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
- clone_flags, arg);
#endif
return ret;
-- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi,
Quoted 8 lines
Acked-by Hannu Heikkinen <[email protected]>
Br,
Hannu
--
Hannu Heikkinen
http://www.nixu.com
Thanks, Hannu
Hi,
I was thinking your patch once again, and I think it would be wiser if we would have something like:
--- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.000000000 +0300
+++ lib/cloner.c 2010-09-03 14:48:20.000000000 +0300
(quoted diff) +11 -1
@@ -43,6 +43,16 @@
 pid_t *parent_tid, void *tls, pid_t *child_tid);
 #endif
 
+/*
+ * Most arch really want to have stack aligned to some sane boundary.
+ */
+#ifdef __arm__
+#define ALIGN_STACK(stack) \
+ ((void *)(((unsigned long)stack) & ~((sizeof(void *)) - 1)))
+#else
+#define ALIGN_STACK(stack) (stack)
+#endif
+
 /***********************************************************************
 * ltp_clone: wrapper for clone to hide the architecture dependencies.
 * 1. hppa takes bottom of stack and no stacksize (stack grows up)
@@ -60,7 +70,7 @@
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
 #else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
+ ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL),
 clone_flags, arg);
 #endif

Quoted 8 lines

The above patch iis in use in our ARM based LTP test suite. Note that -1 is needed for not clobbering eg possibly malloced area after child stack. Could u please change that prev patch a bit, for ensuring that child stack is in proper size etc. Above patch is not sufficient, because ALIGN_STACK in that is only used for arm archs.
br,
Hannu

Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.

Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.

I would just leave the LTP_clone passing the argument to the clone as they came from the caller.

Regards,
Carmelo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyp0OsACgkQoRq/3BrK1s+TPwCgnoZlDNW0yMjfLZAu6gKzywP7 Bp4AoLpYpxtqjtd+tL4+ZpxNhnQv7fpF
=VGJo
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Garrett Cooper

2010-10-04 13:28 UTC #6 lore raw

Quoted 144 lines · Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 125 lines · Hannu Heikkinen
On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
Quoted 75 lines · Hannu Heikkinen
Quoted 8 lines · ext Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Carmelo AMOROSO
Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Quoted 17 lines
Quoted 17 lines
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.
On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch
Quoted 10 lines
Quoted 2 lines
Best regards,
Carmelo
Hi,
any feedback on this ?
Cheers,
Carmelo
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Signed-off-by Carmelo Amoroso <[email protected]>
---
lib/cloner.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
lib/cloner.c +2 -3
index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void
 *arg), void *arg,
 ret = clone(fn, stack, clone_flags, arg);
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
-#elif defined(__arm__)
+#else
 /*
- * Stack size should be a multiple of 32 bit words
- * & stack limit must be aligned to a 32 bit boundary
+ * For archs where stack grows downwards, stack points to the topmost
address
+ * of the memory space set up for the child stack. */
ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg);
-#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
- clone_flags, arg);
#endif
return ret;
-- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi,
Quoted 8 lines
Acked-by Hannu Heikkinen <[email protected]>
Br,
Hannu
--
Hannu Heikkinen
http://www.nixu.com
Thanks, Hannu
Hi,
I was thinking your patch once again, and I think it would be wiser if we would have something like:
--- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.000000000 +0300
+++ lib/cloner.c 2010-09-03 14:48:20.000000000 +0300
(quoted diff) +11 -1
@@ -43,6 +43,16 @@
 pid_t *parent_tid, void *tls, pid_t *child_tid);
 #endif
 
+/*
+ * Most arch really want to have stack aligned to some sane boundary.
+ */
+#ifdef __arm__
+#define ALIGN_STACK(stack) \
+ ((void *)(((unsigned long)stack) & ~((sizeof(void *)) - 1)))
+#else
+#define ALIGN_STACK(stack) (stack)
+#endif
+
 /***********************************************************************
 * ltp_clone: wrapper for clone to hide the architecture dependencies.
 * 1. hppa takes bottom of stack and no stacksize (stack grows up)
@@ -60,7 +70,7 @@
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
 #else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
+ ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL),
 clone_flags, arg);
 #endif
Quoted 8 lines
The above patch iis in use in our ARM based LTP test suite. Note that -1 is needed for not clobbering eg possibly malloced area after child stack. Could u please change that prev patch a bit, for ensuring that child stack is in proper size etc. Above patch is not sufficient, because ALIGN_STACK in that is only used for arm archs.
br,
Hannu
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.

Quoted 6 lines

Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.

I believe this is already handled to some degree with the clone
testcases. If not that should be added and I'll review patches which add this testing to LTP.
On a semi-unrelated note could you guys please test out the
attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc?
Thanks,
-Garrett

testcases/kernel/syscalls/clone/clone01.c +0 -1

index 89992a6..def8007 100644
@@ -79,7 +79,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 static void setup();
 static void cleanup();

testcases/kernel/syscalls/clone/clone02.c +0 -2

index e65702e..718ab47 100644
@@ -113,8 +113,6 @@
 #define TRUE 1
 #define FALSE 0
 
-#include "clone_platform.h"
-
 static void setup();
 static int test_setup();
 static void cleanup();

testcases/kernel/syscalls/clone/clone03.c +0 -2

index 2d60ceb..0a49662 100644
@@ -77,8 +77,6 @@
 #include "test.h"
 #include "usctest.h"
 
-#include "clone_platform.h"
-
 static void setup();
 static void cleanup();
 static int child_fn();

testcases/kernel/syscalls/clone/clone04.c +0 -1

index f5016f7..c14fd81 100644
@@ -76,7 +76,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 static void cleanup(void);
 static void setup(void);

testcases/kernel/syscalls/clone/clone05.c +0 -1

index 73ca2e6..2018581 100644
@@ -75,7 +75,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 #define FLAG CLONE_VM | CLONE_VFORK

testcases/kernel/syscalls/clone/clone06.c +0 -1

index a4d6f07..74c4c8a 100644
@@ -81,7 +81,6 @@
 #include <fcntl.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 #define MAX_LINE_LENGTH 256

testcases/kernel/syscalls/clone/clone07.c +0 -1

index f68099a..cd927a5 100644
@@ -78,7 +78,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 #define TRUE 1
 #define FALSE 0

_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Hannu Heikkinen

2010-10-04 19:09 UTC #7 lore raw

Quoted 1 line · Garrett Cooper

On Mon, Oct 4, 2010 at 6:04 AM, Carmelo AMOROSO <[email protected]> wrote:

-clip-

Quoted 13 lines

Quoted 6 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Quoted 6 lines
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.

Quoted 8 lines

I believe this is already handled to some degree with the clone
testcases. If not that should be added and I'll review patches which add this testing to LTP.
On a semi-unrelated note could you guys please test out the
attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc?
Thanks,
-Garrett

Hi,

Garret, I did git pull and applied your patch, gcc whined about missing CHILD_STACK_SIZE... is it in your some other patch? IFor the time being I added CHILD_STACK_SIZE into test.h, but is it what you wanted initially?

I can test clones for arm 32-bit (BeagleBoard/Cortex A8) and AMD64 (Debian 64-bit) environments. Sadly I do not have SPARCs, nor s390...

br,
Hannu

Hannu Heikkinen

2010-10-04 20:00 UTC #8 lore raw

In reply to Garrett Cooper

Quoted 9 lines · Garrett Cooper

I believe this is already handled to some degree with the clone
testcases. If not that should be added and I'll review patches which add this testing to LTP.
On a semi-unrelated note could you guys please test out the
attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc?
Thanks,
-Garrett

Hi,

after that CHILD_STACK_SIZE (def for as it has been 16384) tests passed in AMD64 - Debian 64-bit and BeagleBoard 32-bit ARM (std linux-2.6 with omap3_defconfig).

Test files are attached. I ran clones in /opt/ltp/testcases/bin straight.

br,
Hannu

[hannu-debian:~:] uname -a
Linux hannu-debian 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux

root@hannu-debian:/opt/ltp/testcases/bin# cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping	: 1
cpu MHz		: 2099.700
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips	: 4199.40
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping : 1
cpu MHz : 2099.700
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips : 4199.99
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

root@hannu-debian:/opt/ltp/testcases/bin# ./clone01
clone01     1  TPASS  :  clone() returned 7639
root@hannu-debian:/opt/ltp/testcases/bin# ./clone02
clone02     1  TPASS  :  Test Passed
clone02     2  TPASS  :  Test Passed
root@hannu-debian:/opt/ltp/testcases/bin# ./clone03
clone03     1  TPASS  :  Test passed
root@hannu-debian:/opt/ltp/testcases/bin# ./clone04
clone04     1  TPASS  :  expected failure; Got EINVAL
root@hannu-debian:/opt/ltp/testcases/bin# ./clone05
clone05     1  TPASS  :  Test Passed
root@hannu-debian:/opt/ltp/testcases/bin# ./clone06
clone06     1  TPASS  :  Test Passed
root@hannu-debian:/opt/ltp/testcases/bin# ./clone07
clone07     1  TPASS  :  Use of return() in child did not cause SIGSEGV

#1 Test BeagleBoard:

root@beagleboard:/opt/ltp/testcases/bin# uname -a
Linux beagleboard 2.6.36-rc4-08510-g0cbe681-dirty #2 Sat Sep 18 12:54:00 EEST 2010 armv7l unknown

root@beagleboard:/opt/ltp/testcases/bin# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 3 (v7l)
BogoMIPS        : 482.11
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0xc08
CPU revision    : 3

Hardware : OMAP3 Beagle Board
Revision : 0020
Serial : 0000000000000000

root@beagleboard:/opt/ltp/testcases/bin# ./clone01
clone01     1  TPASS  :  clone() returned 1957
root@beagleboard:/opt/ltp/testcases/bin# ./clone02
clone02     1  TPASS  :  Test Passed
clone02     2  TPASS  :  Test Passed
root@beagleboard:/opt/ltp/testcases/bin# ./clone03
clone03     1  TPASS  :  Test passed
root@beagleboard:/opt/ltp/testcases/bin# ./clone04
clone04     1  TPASS  :  expected failure; Got EINVAL
root@beagleboard:/opt/ltp/testcases/bin# ./clone05
clone05     1  TPASS  :  Test Passed
root@beagleboard:/opt/ltp/testcases/bin# ./clone06
clone06     1  TPASS  :  Test Passed
root@beagleboard:/opt/ltp/testcases/bin# ./clone07
clone07     1  TPASS  :  Use of return() in child did not cause SIGSEGV

_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Garrett Cooper

2010-10-04 20:57 UTC #9 lore raw

Quoted 11 lines · Hannu Heikkinen

Quoted 9 lines · Garrett Cooper
I believe this is already handled to some degree with the clone testcases. If not that should be added and I'll review patches which add this testing to LTP.
On a semi-unrelated note could you guys please test out the attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc?
Thanks,
-Garrett

Quoted 7 lines

Hi,
after that CHILD_STACK_SIZE (def for as it has been 16384) tests passed in AMD64 - Debian 64-bit and BeagleBoard 32-bit ARM (std linux-2.6 with omap3_defconfig).
Test files are attached. I ran clones in /opt/ltp/testcases/bin straight.

Good catch :). It's always fun making changes when your primary
box isn't linux anymore, dealing with VMs in a minor pain, and you miss an important minor detail :/.
The point of the proposed change was to remove all duplicate
macros from the LTP clone header because I noticed some were defined twice, and over time bitrotted code tends to negatively affect tests in the source base (in particular because someone changes one bit of code and completely ignores/overlooks N-1 other copies of that exact piece of duplicated code -- I've been known to do this by accident as well)...
Thanks for testing!
-Garrett

Carmelo AMOROSO

author

2010-10-05 06:06 UTC #10 lore raw

In reply to Garrett Cooper

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 150 lines · Garrett Cooper

Quoted 17 lines · Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 13 lines · Hannu Heikkinen
On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
Quoted 11 lines · Hannu Heikkinen
Quoted 8 lines · ext Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Carmelo AMOROSO
Folks,
I want to reopen an old discussion on ltp_clone and stack alignment issue (see
http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
Quoted 131 lines
Quoted 112 lines
Quoted 64 lines
Quoted 17 lines
Quoted 17 lines
Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards.
Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer).
So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack.
On my SH4 arch, the stack must be 4byte aligned (as in ARM).
Please, find attached a patch against master branch
Quoted 10 lines
Quoted 2 lines
Best regards,
Carmelo
Hi,
any feedback on this ?
Cheers,
Carmelo
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Signed-off-by Carmelo Amoroso <[email protected]>
---
lib/cloner.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
lib/cloner.c +2 -3
index 6ad4a00..e53c9cf 100644
@@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void
 *arg), void *arg,
 ret = clone(fn, stack, clone_flags, arg);
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
-#elif defined(__arm__)
+#else
 /*
- * Stack size should be a multiple of 32 bit words
- * & stack limit must be aligned to a 32 bit boundary
+ * For archs where stack grows downwards, stack points to the topmost
address
+ * of the memory space set up for the child stack. */
ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg);
-#else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
- clone_flags, arg);
#endif
return ret;
-- <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi,
Quoted 8 lines
Acked-by Hannu Heikkinen <[email protected]>
Br,
Hannu
--
Hannu Heikkinen
http://www.nixu.com
Thanks, Hannu
Hi,
I was thinking your patch once again, and I think it would be wiser if we would have something like:
--- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.000000000 +0300
+++ lib/cloner.c 2010-09-03 14:48:20.000000000 +0300
(quoted diff) +11 -1
@@ -43,6 +43,16 @@
 pid_t *parent_tid, void *tls, pid_t *child_tid);
 #endif
 
+/*
+ * Most arch really want to have stack aligned to some sane boundary.
+ */
+#ifdef __arm__
+#define ALIGN_STACK(stack) \
+ ((void *)(((unsigned long)stack) & ~((sizeof(void *)) - 1)))
+#else
+#define ALIGN_STACK(stack) (stack)
+#endif
+
 /***********************************************************************
 * ltp_clone: wrapper for clone to hide the architecture dependencies.
 * 1. hppa takes bottom of stack and no stacksize (stack grows up)
@@ -60,7 +70,7 @@
 #elif defined(__ia64__)
 ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
 NULL);
 #else
- ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
+ ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL),
 clone_flags, arg);
 #endif
Quoted 8 lines
The above patch iis in use in our ARM based LTP test suite. Note that -1 is needed for not clobbering eg possibly malloced area after child stack. Could u please change that prev patch a bit, for ensuring that child stack is in proper size etc. Above patch is not sufficient, because ALIGN_STACK in that is only used for arm archs.
br,
Hannu
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.

Quoted 6 lines

Quoted 2 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
I believe this is already handled to some degree with the clone testcases. If not that should be added and I'll review patches which add this testing to LTP.

No it doesn't, otherwise those tests would have failed on SH and ARM that do not accept unaligned stack, instead they were all failing just because in all cases the stack argument was unaligned due to - 1.

I will think again if it's worth to add a check in clone code to protected against unaligned stack forcing the clone to fail... not sure what all other cpu are actually doing.

Carmelo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyqwDYACgkQoRq/3BrK1s8UBQCfU5i7oyJD5/qZukRXKDGLjZ1x I+AAoNyn0mUvSL6ZhH5HsAeLQM0uX2Td
=DYlP
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Hannu Heikkinen

2010-10-04 19:06 UTC #11 lore raw

In reply to Carmelo AMOROSO

On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-

Quoted 10 lines

Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.

Quoted 6 lines

I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo

Hi Carmelo,

you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.

br,
Hannu

Carmelo AMOROSO

author

2010-11-09 11:25 UTC #12 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 21 lines · Hannu Heikkinen

On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-
Quoted 10 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
Quoted 6 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo
Hi Carmelo,

Quoted 8 lines

you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.
br,
Hannu

Folks,
any change to get this included for the next release ?

Carmelo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzZL2sACgkQoRq/3BrK1s/jqwCfakEHVCtM3Rpfx6rKU1MlXz5H g4oAmwQ/VMZPc3IxkhKa0Tmgni7K1+zS
=MrS2
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Subrata Modak

2010-11-11 07:57 UTC #13 lore raw

Quoted 30 lines · Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 26 lines · Hannu Heikkinen
On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-
Quoted 10 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
Quoted 6 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo
Hi Carmelo,
you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.

Quoted 6 lines

Quoted 3 lines
br,
Hannu
Folks,
any change to get this included for the next release ?

Did we miss any patch here ?

Regards--
Subrata

Quoted 12 lines

Carmelo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzZL2sACgkQoRq/3BrK1s/jqwCfakEHVCtM3Rpfx6rKU1MlXz5H g4oAmwQ/VMZPc3IxkhKa0Tmgni7K1+zS
=MrS2
-----END PGP SIGNATURE-----

Quoted 10 lines

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Carmelo AMOROSO

author

2010-11-11 08:11 UTC #14 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 28 lines · Subrata Modak

On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote:
Quoted 25 lines · Hannu Heikkinen
On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-
Quoted 10 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
Quoted 6 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo
Hi Carmelo,
you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.

Quoted 9 lines

Quoted 2 lines
br,
Hannu
Folks,
any change to get this included for the next release ?
Quoted 1 line
Did we miss any patch here ?

I think so: this one
http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list

Cheers,
carmelo

Quoted 7 lines

Quoted 2 lines
Regards--
Subrata
Carmelo
Quoted 1 line

-
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzbpIcACgkQoRq/3BrK1s9NrwCeNwTM5Nwp3nqF+UtY0GvYNyR4 7tsAnA0BgHUYggQYXFfmK7zForgxDnpy
=UwIh
-----END PGP SIGNATURE-----

Garrett Cooper

2010-11-11 09:59 UTC #15 lore raw

Quoted 36 lines · Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 32 lines · Subrata Modak
On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote:
Quoted 28 lines · Hannu Heikkinen
On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-
Quoted 10 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
Quoted 6 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo
Hi Carmelo,
you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.
br,
Hannu

Quoted 8 lines

Quoted 5 lines
Folks,
any change to get this included for the next release ?
Quoted 1 line
Did we miss any patch here ?
I think so: this one
http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list

Is the above patch endian agnostic?

Carmelo AMOROSO

author

2010-11-15 07:32 UTC #16 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 44 lines · Garrett Cooper

Quoted 42 lines · Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 37 lines · Subrata Modak
On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote:
Quoted 21 lines · Hannu Heikkinen
On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-
Quoted 10 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
Quoted 6 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo
Hi Carmelo,
Quoted 7 lines
you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.
br,
Hannu
Folks,
any change to get this included for the next release ?
Quoted 1 line
Did we miss any patch here ?

Quoted 7 lines

Quoted 2 lines
I think so: this one
http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list>
Is the above patch endian agnostic?

Yes, definitely. The patch just removed an wrong manipulation of the stack arguments for all the archs.

Carmelo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzg4UwACgkQoRq/3BrK1s+HEwCfWmFi6vBpxB6V1JQMEWyYy7z+ KbkAn3LcNtU+a/6RCfAOvr3Q/xFGrJrt
=dQgU
-----END PGP SIGNATURE-----

Garrett Cooper

2010-11-21 03:34 UTC #17 lore raw

Quoted 53 lines · Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 49 lines · Garrett Cooper
On Thu, Nov 11, 2010 at 12:08 AM, Carmelo AMOROSO <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/11/2010 8:57 AM, Subrata Modak wrote:
>> On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote:
>> On 10/4/2010 9:05 PM, Hannu Heikkinen wrote:
>>> On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
>>> -clip-
>>> >
>>> > Hannu,
>>> > I don't think that it is a good to force the alignment; we could need to >>> > write a test case that calls LTP_clone with an unaligned stack just to >>> > test the behavior of the clone implementation.
>>> >
>>> > Likely, it should be useful to add a check inside the C lib clone >>> > implementation (arch specific) to protect against unaligned stack, but >>> > this is a different matter.
>>> >
>>> > I would just leave the LTP_clone passing the argument to the clone as >>> > they came from the caller.
>>> >
>>> > Regards,
>>> > Carmelo
>>> >
>>
>>> Hi Carmelo,
>>
>>> you've got point, yes. I was just so worried about the fact that in ARM >>> architectures that previous eg clone02 failed due to alignment errors. >>> But your fix of course fixed that issue, and it gives as a possiblity >>> to make test case against alignment issues, quite right.
>>
>>> br,
>>> Hannu
>>
>>
>> Folks,
>> any change to get this included for the next release ?
>>
>>> Did we miss any patch here ?
>>
>
> I think so: this one
>
http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list>

Quoted 5 lines

Quoted 2 lines
Is the above patch endian agnostic?
Yes, definitely. The patch just removed an wrong manipulation of the stack arguments for all the archs.

I'm going to test it in just a bit, but please let me know if you
run into any issues.
Thanks,
-Garrett

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Carmelo AMOROSO

author

2010-11-24 08:32 UTC #18 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 59 lines · Garrett Cooper

Quoted 51 lines · Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 47 lines · Garrett Cooper
Quoted 44 lines · Carmelo AMOROSO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 28 lines · Subrata Modak
On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote:
Quoted 25 lines · Hannu Heikkinen
On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
-clip-
Quoted 10 lines
Hannu,
I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation.
Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter.
Quoted 6 lines
I would just leave the LTP_clone passing the argument to the clone as they came from the caller.
Regards,
Carmelo
Hi Carmelo,
you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right.
Quoted 9 lines
Quoted 2 lines
br,
Hannu
Folks,
any change to get this included for the next release ?
Quoted 1 line
Did we miss any patch here ?
I think so: this one
http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list>
Quoted 1 line
Quoted 1 line
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list>>
Quoted 1 line
Quoted 1 line

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Is the above patch endian agnostic?
Yes, definitely. The patch just removed an wrong manipulation of the stack arguments for all the archs.
I'm going to test it in just a bit, but please let me know if you run into any issues.

No issues.

Carmelo

Quoted 3 lines

Thanks,
-Garrett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzszTcACgkQoRq/3BrK1s97UQCeJEiAisHHlmqwNuaNGhXZuVAJ ercAoL9ysW+cGly5vDI3c7cy7o2SGni1
=teZB
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Garrett Cooper

2010-11-24 08:44 UTC #19 lore raw

Quoted 69 lines · Carmelo AMOROSO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 65 lines · Garrett Cooper
On Sun, Nov 14, 2010 at 11:29 PM, Carmelo AMOROSO <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/11/2010 10:59 AM, Garrett Cooper wrote:
>> On Thu, Nov 11, 2010 at 12:08 AM, Carmelo AMOROSO
>> <[email protected]> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 11/11/2010 8:57 AM, Subrata Modak wrote:
>> >> On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote:
>> >> On 10/4/2010 9:05 PM, Hannu Heikkinen wrote:
>> >>> On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote:
>> >>> -clip-
>> >>> >
>> >>> > Hannu,
>> >>> > I don't think that it is a good to force the alignment; we could need to >> >>> > write a test case that calls LTP_clone with an unaligned stack just to >> >>> > test the behavior of the clone implementation.
>> >>> >
>> >>> > Likely, it should be useful to add a check inside the C lib clone >> >>> > implementation (arch specific) to protect against unaligned stack, but >> >>> > this is a different matter.
>> >>> >
>> >>> > I would just leave the LTP_clone passing the argument to the clone as >> >>> > they came from the caller.
>> >>> >
>> >>> > Regards,
>> >>> > Carmelo
>> >>> >
>> >>
>> >>> Hi Carmelo,
>> >>
>> >>> you've got point, yes. I was just so worried about the fact that in ARM >> >>> architectures that previous eg clone02 failed due to alignment errors. >> >>> But your fix of course fixed that issue, and it gives as a possiblity >> >>> to make test case against alignment issues, quite right.
>> >>
>> >>> br,
>> >>> Hannu
>> >>
>> >>
>> >> Folks,
>> >> any change to get this included for the next release ?
>> >>
>> >>> Did we miss any patch here ?
>> >>
>> >
>> > I think so: this one
>> >
>>
http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list>
>>
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list
<http://sourceforge.net/mailarchive/forum.php?thread_name=4CA09D4D.6050708%40st.com&forum_name=ltp-list>>
>>
>> Is the above patch endian agnostic?
>>
>
> Yes, definitely. The patch just removed an wrong manipulation of the > stack arguments for all the archs.

Quoted 4 lines

Quoted 2 lines
I'm going to test it in just a bit, but please let me know if you run into any issues.
No issues.

Thanks for your testing and persistence in the issue. -Garrett