[LTP] ltp_clone alignment issues.

[LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

-----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-----

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lib-Fix-ltp_clone-wrapper-stack-argument-for-all-arc.patch --]
[-- Type: text/x-patch; name="0001-lib-Fix-ltp_clone-wrapper-stack-argument-for-all-arc.patch", Size: 1797 bytes --]

From 9393da0a1a6959cc5d25f73be63baf8c3fae8762 Mon Sep 17 00:00:00 2001
From: Carmelo Amoroso <carmelo.amoroso@st.com>
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 <carmelo.amoroso@st.com>
---
 lib/cloner.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/lib/cloner.c b/lib/cloner.c
index 6ad4a00..e53c9cf 100644
--- a/lib/cloner.c
+++ b/lib/cloner.c
@@ -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;
-- 
1.7.1


[-- Attachment #3: Type: text/plain, Size: 276 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

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

On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
> 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

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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Hannu Heikkinen]

On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
> > 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
> 
> Hi,
> any feedback on this ?
> 
> Cheers,
> Carmelo

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
---
 lib/cloner.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/lib/cloner.c b/lib/cloner.c
index 6ad4a00..e53c9cf 100644
--- a/lib/cloner.c
+++ b/lib/cloner.c
@@ -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,

Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>

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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

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

On 9/30/2010 3:31 PM, Hannu Heikkinen wrote:
> On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
>  > > 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
>  >
>  > Hi,
>  > any feedback on this ?
>  >
>  > Cheers,
>  > Carmelo
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
> ---
> lib/cloner.c | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/cloner.c b/lib/cloner.c
> index 6ad4a00..e53c9cf 100644
> --- a/lib/cloner.c
> +++ b/lib/cloner.c
> @@ -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,
> 
> Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>
> 
> 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-----

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Hannu Heikkinen]

On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 9/30/2010 3:31 PM, Hannu Heikkinen wrote:
> > On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
> >  > -----BEGIN PGP SIGNED MESSAGE-----
> >  > Hash: SHA1
> >  >
> >  > On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
> >  > > 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
> >  >
> >  > Hi,
> >  > any feedback on this ?
> >  >
> >  > Cheers,
> >  > Carmelo
> > 
> >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
> > ---
> > lib/cloner.c | 9 +++------
> > 1 files changed, 3 insertions(+), 6 deletions(-)
> > 
> > diff --git a/lib/cloner.c b/lib/cloner.c
> > index 6ad4a00..e53c9cf 100644
> > --- a/lib/cloner.c
> > +++ b/lib/cloner.c
> > @@ -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,
> > 
> > Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>
> > 
> > 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-----

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

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

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

On 10/1/2010 6:06 AM, Hannu Heikkinen wrote:
> On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
> On 9/30/2010 3:31 PM, Hannu Heikkinen wrote:
>> On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
>> > > 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
>> >
>> > Hi,
>> > any feedback on this ?
>> >
>> > Cheers,
>> > Carmelo
> 
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
>> ---
>> lib/cloner.c | 9 +++------
>> 1 files changed, 3 insertions(+), 6 deletions(-)
> 
>> diff --git a/lib/cloner.c b/lib/cloner.c
>> index 6ad4a00..e53c9cf 100644
>> --- a/lib/cloner.c
>> +++ b/lib/cloner.c
>> @@ -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,
> 
>> Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>
> 
>> 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
> @@ -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


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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Garrett Cooper]

[-- Attachment #1: Type: text/plain, Size: 5377 bytes --]

On Mon, Oct 4, 2010 at 6:04 AM, Carmelo AMOROSO <carmelo.amoroso@st.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/1/2010 6:06 AM, Hannu Heikkinen wrote:
>> On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
>> On 9/30/2010 3:31 PM, Hannu Heikkinen wrote:
>>> On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
>>> > -----BEGIN PGP SIGNED MESSAGE-----
>>> > Hash: SHA1
>>> >
>>> > On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
>>> > > 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
>>> >
>>> > Hi,
>>> > any feedback on this ?
>>> >
>>> > Cheers,
>>> > Carmelo
>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
>>> ---
>>> lib/cloner.c | 9 +++------
>>> 1 files changed, 3 insertions(+), 6 deletions(-)
>>
>>> diff --git a/lib/cloner.c b/lib/cloner.c
>>> index 6ad4a00..e53c9cf 100644
>>> --- a/lib/cloner.c
>>> +++ b/lib/cloner.c
>>> @@ -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,
>>
>>> Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>
>>
>>> 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
>> @@ -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
>
>
> 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.

    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

[-- Attachment #2: remove-clone-platform.diff --]
[-- Type: application/octet-stream, Size: 2660 bytes --]

diff --git a/testcases/kernel/syscalls/clone/clone01.c b/testcases/kernel/syscalls/clone/clone01.c
index 89992a6..def8007 100644
--- a/testcases/kernel/syscalls/clone/clone01.c
+++ b/testcases/kernel/syscalls/clone/clone01.c
@@ -79,7 +79,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 static void setup();
 static void cleanup();
diff --git a/testcases/kernel/syscalls/clone/clone02.c b/testcases/kernel/syscalls/clone/clone02.c
index e65702e..718ab47 100644
--- a/testcases/kernel/syscalls/clone/clone02.c
+++ b/testcases/kernel/syscalls/clone/clone02.c
@@ -113,8 +113,6 @@
 #define TRUE 1
 #define FALSE 0
 
-#include "clone_platform.h"
-
 static void setup();
 static int test_setup();
 static void cleanup();
diff --git a/testcases/kernel/syscalls/clone/clone03.c b/testcases/kernel/syscalls/clone/clone03.c
index 2d60ceb..0a49662 100644
--- a/testcases/kernel/syscalls/clone/clone03.c
+++ b/testcases/kernel/syscalls/clone/clone03.c
@@ -77,8 +77,6 @@
 #include "test.h"
 #include "usctest.h"
 
-#include "clone_platform.h"
-
 static void setup();
 static void cleanup();
 static int child_fn();
diff --git a/testcases/kernel/syscalls/clone/clone04.c b/testcases/kernel/syscalls/clone/clone04.c
index f5016f7..c14fd81 100644
--- a/testcases/kernel/syscalls/clone/clone04.c
+++ b/testcases/kernel/syscalls/clone/clone04.c
@@ -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);
diff --git a/testcases/kernel/syscalls/clone/clone05.c b/testcases/kernel/syscalls/clone/clone05.c
index 73ca2e6..2018581 100644
--- a/testcases/kernel/syscalls/clone/clone05.c
+++ b/testcases/kernel/syscalls/clone/clone05.c
@@ -75,7 +75,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 #define FLAG CLONE_VM | CLONE_VFORK
 
diff --git a/testcases/kernel/syscalls/clone/clone06.c b/testcases/kernel/syscalls/clone/clone06.c
index a4d6f07..74c4c8a 100644
--- a/testcases/kernel/syscalls/clone/clone06.c
+++ b/testcases/kernel/syscalls/clone/clone06.c
@@ -81,7 +81,6 @@
 #include <fcntl.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 #define MAX_LINE_LENGTH 256
 
diff --git a/testcases/kernel/syscalls/clone/clone07.c b/testcases/kernel/syscalls/clone/clone07.c
index f68099a..cd927a5 100644
--- a/testcases/kernel/syscalls/clone/clone07.c
+++ b/testcases/kernel/syscalls/clone/clone07.c
@@ -78,7 +78,6 @@
 #include <sys/wait.h>
 #include "test.h"
 #include "usctest.h"
-#include "clone_platform.h"
 
 #define TRUE 1
 #define FALSE 0

[-- Attachment #3: Type: text/plain, Size: 368 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Hannu Heikkinen]

On 04/10/10 06:28 -0700, Garrett Cooper wrote:
> On Mon, Oct 4, 2010 at 6:04 AM, Carmelo AMOROSO <carmelo.amoroso@st.com> 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.
> 
>     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

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Hannu Heikkinen]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On 04/10/10 06:28 -0700, Garrett Cooper wrote:
> 
>     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


[-- Attachment #2: clone-test-amd64 --]
[-- Type: text/plain, Size: 2420 bytes --]

[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




[-- Attachment #3: clone-test-arm32 --]
[-- Type: text/plain, Size: 1293 bytes --]

#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



[-- Attachment #4: Type: text/plain, Size: 368 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #5: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Garrett Cooper]

On Mon, Oct 4, 2010 at 1:00 PM, Hannu Heikkinen <hannuxx@iki.fi> wrote:
> On 04/10/10 06:28 -0700, Garrett Cooper wrote:
>>
>>     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.

    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

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

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

On 10/4/2010 3:28 PM, Garrett Cooper wrote:
> On Mon, Oct 4, 2010 at 6:04 AM, Carmelo AMOROSO <carmelo.amoroso@st.com> wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > On 10/1/2010 6:06 AM, Hannu Heikkinen wrote:
>  >> On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
>  >> On 9/30/2010 3:31 PM, Hannu Heikkinen wrote:
>  >>> On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
>  >>> > -----BEGIN PGP SIGNED MESSAGE-----
>  >>> > Hash: SHA1
>  >>> >
>  >>> > On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
>  >>> > > 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
>  >>> >
>  >>> > Hi,
>  >>> > any feedback on this ?
>  >>> >
>  >>> > Cheers,
>  >>> > Carmelo
>  >>
>  >>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>  >>> Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
>  >>> ---
>  >>> lib/cloner.c | 9 +++------
>  >>> 1 files changed, 3 insertions(+), 6 deletions(-)
>  >>
>  >>> diff --git a/lib/cloner.c b/lib/cloner.c
>  >>> index 6ad4a00..e53c9cf 100644
>  >>> --- a/lib/cloner.c
>  >>> +++ b/lib/cloner.c
>  >>> @@ -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,
>  >>
>  >>> Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>
>  >>
>  >>> 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
>  >> @@ -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
>  >
>  >
>  > 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.
> 
> 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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Hannu Heikkinen]

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

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

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

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 ?

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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Subrata Modak]

On Tue, 2010-11-09 at 12:24 +0100, Carmelo AMOROSO wrote: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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 ?

Regards--
Subrata

> 
> 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
> Ltp-list@lists.sourceforge.net
> 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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

-----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

Cheers,
carmelo

>> Regards--
>> Subrata
> 
> 
> Carmelo
> 
>  >
-
------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
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-----

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Garrett Cooper]

On Thu, Nov 11, 2010 at 12:08 AM, Carmelo AMOROSO
<carmelo.amoroso@st.com> 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

Is the above patch endian agnostic?

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

-----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
> <carmelo.amoroso@st.com> 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>
> 
> 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-----

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Garrett Cooper]

On Sun, Nov 14, 2010 at 11:29 PM, Carmelo AMOROSO
<carmelo.amoroso@st.com> 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
>> <carmelo.amoroso@st.com> 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>
>>
>> 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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Carmelo AMOROSO]

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

On 11/21/2010 4:34 AM, Garrett Cooper wrote:
> On Sun, Nov 14, 2010 at 11:29 PM, Carmelo AMOROSO
> <carmelo.amoroso@st.com> 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
>  >> <carmelo.amoroso@st.com> 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.
> 
> I'm going to test it in just a bit, but please let me know if you
> run into any issues.

No issues.

Carmelo
> 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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] ltp_clone alignment issues.

[Garrett Cooper]

On Wed, Nov 24, 2010 at 12:30 AM, Carmelo AMOROSO
<carmelo.amoroso@st.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/21/2010 4:34 AM, Garrett Cooper wrote:
>> On Sun, Nov 14, 2010 at 11:29 PM, Carmelo AMOROSO
>> <carmelo.amoroso@st.com> 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
>>  >> <carmelo.amoroso@st.com> 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.
>>
>> 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

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list