lua-test failure help on Vxworks 7?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

lua-test failure help on Vxworks 7?

Kuhl, Brian
Hi Lua experts,
<re-post in plain text>
I’d appreciate any hints that might not be obvious to the new user.
I’m working on a port of Lua 5.3.5 to the current VxWorks 7, (patch below).  I’m an employee of Wind River that specializes in porting 3rd party software to VxWorks. But I don’t know Lua.
I’m running the 5.3.4 test suite and getting failures in few places, I’ll be slowly be debugging them over the coming weeks as side project.
I’m not using the testC library yet. I’ll get there ☺

I’ve compiled Lua as VxWorks process and was able to get though failures in errors.lua and coroutine.lua just by increasing the default stacks that VxWorks uses.
Leaving failures in:
• main.lua
• strings.lua
• files.lua
• attrib.lua

main.lua
=======
Assumes a real UNIX user shell, which I don’t have in VX. So let’s leave that one for now. (I was able to get the first test to pass by an update to our system() function. But the rest doesn’t look promising.)

strings.lua
========
Looks like tonumber() is not my friend for some reason. I’m on possibly related internal thread on similar issues with the VxWorks C library.  
What’s different between the C calls that string.format() uses vs. what tonumber()  uses??
   
failed assert strings.lua:226
do    -- longest number that can be formatted
  local i = 1
  local j = 10000
  while i + 1 < j do   -- binary search for maximum finite float
    local m = (i + j) // 2
    if 10^m < math.huge then i = m else j = m end
  end
  local s = string.format('%.99f', -(10^i))
  assert(tonumber(s) == -(10^i))
end
  
files.lua
======
This I have to call this with _ports == true, to avoid the tests using popen(), which VxWorks doesn’t have.

I still get a failure in this assert:
do
  local D = os.date("*t")
  local t = os.time(D)
  assert(type(D.isdst) == 'boolean')
end


attrib.lua
=======
VxWorks has a striped down port of the shared library loader from BSD.
So I expect this to test suite to pass, but I expect my patch will need some work.
Any hints where to start?

The first failure was an assert at line 246
assert(not f and type(err) == "string" and when == "absent")

I comment that out and get the following on the console.
Process 'lua.vxe' (process Id = 0x400c551e0) launched.
testing require
package config: /|;|?|!|-|
+

>>> cannot load dynamic library <<<

_rtld_exclusive_exit :: called
        open
+
testing assignments, logical operators, and constructors
+
OK


Brian Kuhl
Senior Manager – Information Development
Wind River

-----------------
diff -uNdr lua-5.3.5/src/lauxlib.c lua-5.3.5.patched/src/lauxlib.c
--- lua-5.3.5/src/lauxlib.c      2017-04-19 13:20:42.000000000 -0400
+++ lua-5.3.5/src/lauxlib.c      2019-04-03 12:58:06.863586237 -0400
@@ -251,7 +251,7 @@

 #if !defined(l_inspectstat)     /* { */

-#if defined(LUA_USE_POSIX)
+#if defined(LUA_USE_BASIC_POSIX)

 #include <sys/wait.h>

diff -uNdr lua-5.3.5/src/ldo.c lua-5.3.5/src/ldo.c
--- lua-5.3.5/src/ldo.c    2017-04-19 13:20:42.000000000 -0400
+++ lua-5.3.5/src/ldo.c    2019-04-03 12:37:40.274830919 -0400
@@ -60,7 +60,7 @@
      try { a } catch(...) { if ((c)->status == 0) (c)->status = -1; }
#define luai_jmpbuf             int  /* dummy variable */

-#elif defined(LUA_USE_POSIX)                        /* }{ */
+#elif defined(LUA_USE__LONGJMP) /* }{ */

 /* in POSIX, try _longjmp/_setjmp (more efficient) */
#define LUAI_THROW(L,c)         _longjmp((c)->b, 1)
diff -uNdr lua-5.3.5/src/liolib.c lua-5.3.5.patched/src/liolib.c
--- lua-5.3.5/src/liolib.c 2017-04-19 13:29:57.000000000 -0400
+++ lua-5.3.5/src/liolib.c 2019-04-03 13:04:53.015806349 -0400
@@ -54,7 +54,7 @@

 #if !defined(l_popen)           /* { */

-#if defined(LUA_USE_POSIX)      /* { */
+#if defined(LUA_USE_POPEN)      /* { */

 #define l_popen(L,c,m)          (fflush(NULL), popen(c,m))
#define l_pclose(L,file)  (pclose(file))
@@ -82,7 +82,7 @@

 #if !defined(l_getc)            /* { */

-#if defined(LUA_USE_POSIX)
+#if defined(LUA_USE_BASIC_POSIX)
#define l_getc(f)         getc_unlocked(f)
#define l_lockfile(f)           flockfile(f)
#define l_unlockfile(f)         funlockfile(f)
@@ -103,7 +103,7 @@

 #if !defined(l_fseek)           /* { */

-#if defined(LUA_USE_POSIX)      /* { */
+#if defined(LUA_USE_BASIC_POSIX) /* { */

 #include <sys/types.h>

diff -uNdr lua-5.3.5/src/lmathlib.c lua-5.3.5.patched/src/lmathlib.c
--- lua-5.3.5/src/lmathlib.c     2017-04-19 13:20:42.000000000 -0400
+++ lua-5.3.5/src/lmathlib.c     2019-04-03 12:33:32.122661838 -0400
@@ -24,7 +24,7 @@

 
 #if !defined(l_rand)            /* { */
-#if defined(LUA_USE_POSIX)
+#if defined(LUA_USE_RANDOM)
#define l_rand()   random()
#define l_srand(x) srandom(x)
#define L_RANDMAX  2147483647   /* (2^31 - 1), following POSIX */
diff -uNdr lua-5.3.5/src/loslib.c lua-5.3.5.patched/src/loslib.c
--- lua-5.3.5/src/loslib.c 2017-04-19 13:29:57.000000000 -0400
+++ lua-5.3.5/src/loslib.c 2019-04-03 13:04:52.975806327 -0400
@@ -81,7 +81,7 @@
** where it uses gmtime_r/localtime_r
*/

-#if defined(LUA_USE_POSIX)      /* { */
+#if defined(LUA_USE_BASIC_POSIX) /* { */

 #define l_gmtime(t,r)           gmtime_r(t,r)
#define l_localtime(t,r)  localtime_r(t,r)
@@ -108,7 +108,7 @@
*/
#if !defined(lua_tmpnam)  /* { */

-#if defined(LUA_USE_POSIX)      /* { */
+#if defined(LUA_USE_MKSTEMP)    /* { */

 #include <unistd.h>

diff -uNdr lua-5.3.5/src/lua.c lua-5.3.5.patched/src/lua.c
--- lua-5.3.5/src/lua.c    2017-04-19 13:29:57.000000000 -0400
+++ lua-5.3.5/src/lua.c    2019-04-03 13:04:52.671806169 -0400
@@ -47,7 +47,7 @@
*/
#if !defined(lua_stdin_is_tty)  /* { */

-#if defined(LUA_USE_POSIX)      /* { */
+#if defined(LUA_USE_BASIC_POSIX) /* { */

 #include <unistd.h>
#define lua_stdin_is_tty()      isatty(0)
diff -uNdr lua-5.3.5/src/luaconf.h lua-5.3.5.patched/src/luaconf.h
--- lua-5.3.5/src/luaconf.h      2017-04-19 13:29:57.000000000 -0400
+++ lua-5.3.5/src/luaconf.h      2019-04-03 13:22:13.092296715 -0400
@@ -51,12 +51,14 @@
#define LUA_USE_WINDOWS  /* enable goodies for regular Windows */
#endif

-
#if defined(LUA_USE_WINDOWS)
#define LUA_DL_DLL /* enable support for DLL */
#define LUA_USE_C89       /* broadly, Windows is C89 */
#endif

+#if defined(LUA_USE_VXWORKS)
+#define LUA_USE_BASIC_POSIX
+#endif

 #if defined(LUA_USE_LINUX)
#define LUA_USE_POSIX
@@ -71,6 +73,13 @@
#define LUA_USE_READLINE  /* needs an extra library: -lreadline */
#endif

+#if defined(LUA_USE_POSIX)
+#define LUA_USE_BASIC_POSIX
+#define LUA_USE__LONGJMP
+#define LUA_USE_POPEN
+#define LUA_USE_RANDOM
+#define LUA_USE_MKSTEMP
+#endif

 /*
@@ LUA_C89_NUMBERS ensures that Lua uses the largest types available for
diff -uNdr lua-5.3.5/src/Makefile lua-5.3.5.patched/src/Makefile
--- lua-5.3.5/src/Makefile 2018-06-25 13:46:36.000000000 -0400
+++ lua-5.3.5/src/Makefile 2019-04-03 15:30:01.023135141 -0400
@@ -26,7 +26,7 @@

 # == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE =======

-PLATS= aix bsd c89 freebsd generic linux macosx mingw posix solaris
+PLATS= aix bsd c89 freebsd generic linux macosx mingw posix solaris vxworks

 LUA_A=      liblua.a
CORE_O=     lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o \
@@ -124,6 +124,10 @@
solaris:
      $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN -D_REENTRANT" SYSLIBS="-ldl"

+vxworks:
+      $(MAKE) $(ALL) "LUAC_T=luac.vxe" "LUA_T=lua.vxe" lua.vxe luac.vxe LIBS="" \
+      SYSCFLAGS="-DLUA_USE_VXWORKS -DLUA_USE_DLOPEN -D_XOPEN_SOURCE=0 -DRTLD_LOCAL=0"
+
# list targets that do not create files (but not all makes understand .PHONY)
.PHONY: all $(PLATS) default o a clean depend echo none



Reply | Threaded
Open this post in threaded view
|

Re: lua-test failure help on Vxworks 7?

Roberto Ierusalimschy
> Hi Lua experts,
> <re-post in plain text>
> I’d appreciate any hints that might not be obvious to the new user.
> I’m working on a port of Lua 5.3.5 to the current VxWorks 7, (patch below).  I’m an employee of Wind River that specializes in porting 3rd party software to VxWorks. But I don’t know Lua.
> I’m running the 5.3.4 test suite and getting failures in few places, I’ll be slowly be debugging them over the coming weeks as side project.
> I’m not using the testC library yet. I’ll get there ☺

Did you read the instructions in https://www.lua.org/tests/? You should
really start with the basic tests (that will avoid your problems
with 'main.lua', 'files.lua', and 'attrib.lua'). Once you have that
working, go to the next step. As warned there, beware that the complete
tests are not portable.

> strings.lua
> ========
> Looks like tonumber() is not my friend for some reason. I’m on possibly related internal thread on similar issues with the VxWorks C library.  
> What’s different between the C calls that string.format() uses vs. what tonumber()  uses??
>    
> failed assert strings.lua:226
> do    -- longest number that can be formatted
>   local i = 1
>   local j = 10000
>   while i + 1 < j do   -- binary search for maximum finite float
>     local m = (i + j) // 2
>     if 10^m < math.huge then i = m else j = m end
>   end
>   local s = string.format('%.99f', -(10^i))
>   assert(tonumber(s) == -(10^i))
> end

It would help if you could tell what is happening here. Did you print
the various values produced?

  print(i, 10^i, s, tonumber(s))


> files.lua
> ======
> This I have to call this with _ports == true, to avoid the tests using popen(), which VxWorks doesn’t have.
>
> I still get a failure in this assert:
> do
>   local D = os.date("*t")
>   local t = os.time(D)
>   assert(type(D.isdst) == 'boolean')
> end

Sorry, this test should be coded as not portable. The manual is clear
about this:

    This last field [isdst] may be absent
    if the information is not available.

(Did the previous test work?)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: lua-test failure help on Vxworks 7?

Kuhl, Brian
Hi Roberto,
Many thanks for the reply.  
(I've got all the basic tests to pass already, sorry if I wasn't clear on that?
With the exception of the single tests in strings.lua and files.lua. )

I'm primarily focused on the non-portable tests, which utilize areas where VxWorks has some POSIX support.  
Thanks for the hint about ".isdst"

I drilled down on the string.lua failure and it is an issue with least significant bit in the mantissa returned by VxWorks C library strtod()
There is similar issue with strtof(), but this is the first I've seen a test case for double.

string.lua instrumented :

i is 308.000000
tonumber(string.format('%.99f', -(10^i)) is -0x8.e679c2f5e4528p+1020
                     string.format('%a', -(10^i))    is -0x8.e679c2f5e452p+1020


output from C code below:
d=          10^308  == -0x8.e679c2f5e45200p+1020
d2=  strtod(10^308) == -0x8.e679c2f5e45280p+1020
In function start -- /yow-build62-lx2/bkuhl/workspace/test_strtof/dkm.c:20 d == d2 -- assertion failed


#include "vxWorks.h"
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <assert.h>

void start(void) {
      char * end;
      char buf[400];
      double d2 ;
      double d = -pow(10,308);
      sprintf(buf, "%.99f", d);
      d2 = strtod(buf,&end);

      printf( "\nd=          10^308  == %.14a ", d);
      printf( "\nd2=  strtod(10^308) == %.14a \n", d2);

      assert( d == d2 );
}


Brian



> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Roberto Ierusalimschy
> Sent: Monday, April 08, 2019 11:56 AM
> To: Lua mailing list <[hidden email]>
> Subject: Re: lua-test failure help on Vxworks 7?
>
> > Hi Lua experts,
> > <re-post in plain text>
> > I’d appreciate any hints that might not be obvious to the new user.
> > I’m working on a port of Lua 5.3.5 to the current VxWorks 7, (patch
> below).  I’m an employee of Wind River that specializes in porting 3rd party
> software to VxWorks. But I don’t know Lua.
> > I’m running the 5.3.4 test suite and getting failures in few places, I’ll be slowly
> be debugging them over the coming weeks as side project.
> > I’m not using the testC library yet. I’ll get there ☺
>
> Did you read the instructions in https://www.lua.org/tests/? You should really
> start with the basic tests (that will avoid your problems with 'main.lua',
> 'files.lua', and 'attrib.lua'). Once you have that working, go to the next step. As
> warned there, beware that the complete tests are not portable.
>
> > strings.lua
> > ========
> > Looks like tonumber() is not my friend for some reason. I’m on
> > possibly related internal thread on similar issues with the VxWorks C library.
> What’s different between the C calls that string.format() uses vs. what
> tonumber()  uses??
> >
> > failed assert strings.lua:226
> > do    -- longest number that can be formatted
> >   local i = 1
> >   local j = 10000
> >   while i + 1 < j do   -- binary search for maximum finite float
> >     local m = (i + j) // 2
> >     if 10^m < math.huge then i = m else j = m end
> >   end
> >   local s = string.format('%.99f', -(10^i))
> >   assert(tonumber(s) == -(10^i))
> > end
>
> It would help if you could tell what is happening here. Did you print the various
> values produced?
>
>   print(i, 10^i, s, tonumber(s))
>
>
> > files.lua
> > ======
> > This I have to call this with _ports == true, to avoid the tests using popen(),
> which VxWorks doesn’t have.
> >
> > I still get a failure in this assert:
> > do
> >   local D = os.date("*t")
> >   local t = os.time(D)
> >   assert(type(D.isdst) == 'boolean')
> > end
>
> Sorry, this test should be coded as not portable. The manual is clear about this:
>
>     This last field [isdst] may be absent
>     if the information is not available.
>
> (Did the previous test work?)
>
> -- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lua-test failure help on Vxworks 7?

Roberto Ierusalimschy
> d=          10^308  == -0x8.e679c2f5e45200p+1020
> d2=  strtod(10^308) == -0x8.e679c2f5e45280p+1020
> [...]
>       printf( "\nd=          10^308  == %.14a ", d);
> [...]

A small digression: by the C standard, we should not use '.14' with
'%a': "the [default] precision is sufficient for an exact representation
of the value". In correct systems, they even ensure that all bits
presented are significative, by adjusting the number of bits in the
integer part. So, we do not get those extra non-significative zero bits
in '280p+...'. Instead, we get 0x1.1ccf385ebc8ap+1023. However, I am
not sure the Windows libc respects the standard here...

-- Roberto