JS_Eval returns JS_TAG_UNDEFINED

[vincentparrett]

How do I find the reason why a JS_Eval is returning undefined?

I'm building using MINGW on WSL2 to create windows dll's that are loaded by a Delphi 12.3 application. It is working fine when built for Win32, but for Win64 (it doesn't matter what the script is) it just returns undefined.

Is there way to find out what is going on?

Delphi code

function TContext.Eval(const script, scriptName: string): boolean;
var
  sScript : UTF8String;
  evalRes : JSValue;
begin
  result := false;
  sScript := UTF8Encode(script);
  evalRes := JS_Eval(FContext, PAnsiChar(sScript), Length(sScript),'<eval>',JS_EVAL_TYPE_GLOBAL);
  if JS_IsException(evalRes) then
  begin
    FContext.GetErrorMessage(false, sScript, nil );
    Writeln(string(sScript));
    JS_FreeValue(FContext, evalRes);
    exit(false);
  end;
  result := true;
end;

Make file cobbled together from other examples

ARCH ?= 32

ifeq ($(ARCH),32)
	CC = i686-w64-mingw32-gcc
	CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" 
	LDFLAGS = -static -shared
	RC_COMPILER = i686-w64-mingw32-windres --preprocessor=i686-w64-mingw32-gcc --preprocessor-arg=-E --preprocessor-arg=-xc-header --preprocessor-arg=-DRC_INVOKED
	RC_FLAGS = --target=pe-i386
else
	CC = x86_64-w64-mingw32-gcc
	CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\"
	LDFLAGS = -static -shared
	RC_COMPILER = x86_64-w64-mingw32-windres
	RC_FLAGS = 
endif

OUT_DIR = Win$(ARCH)

RC_FILE = winver.rc
RES_FILE = $(OUT_DIR)/winver.o
SRC = quickjs.c libunicode.c libregexp.c cutils.c xsum.c
OBJS = $(patsubst %.c,$(OUT_DIR)/%.o,$(SRC))
TARGET = $(OUT_DIR)/quickjs-ng$(ARCH).dll

all: $(OUT_DIR) $(TARGET)

$(OUT_DIR):
	mkdir -p $(OUT_DIR)

$(OUT_DIR)/%.o: %.c | $(OUT_DIR)
	$(CC) $(CFLAGS) -c $< -o $@

$(RES_FILE): $(RC_FILE) | $(OUT_DIR)
	$(RC_COMPILER) $(RC_FLAGS) -i $(RC_FILE) -o $(RES_FILE) 

$(TARGET): $(OBJS) $(RES_FILE)
	$(CC) $(LDFLAGS) -o $@ $^

.PHONY: clean

clean:
	rm -rf win$(ARCH)

[bnoordhuis]

What is sizeof(JSValue) in a) your own C code (or Delphi glue code), and b) inside quickjs.c? If there's a mismatch, that's where to start looking.

SRC = quickjs.c libunicode.c libregexp.c cutils.c xsum.c

Maybe use the amalgamation build (quickjs-amalgam.c) instead? That way you don't have to update your makefile when our repository layout changes. Plus, the compiler probably generates a little tighter code because it's a single compilation unit.

[vincentparrett]

Hi

sizeof(JSValue) = 16 bytes in C and in the delphi translation - so it looks like that is not the cause.

I verified in C with

_Static_assert ((sizeof(JSValue) == 16),"sizof JSValue should be 16 bytes");

Delphi doesn't really have compile time assertions but I fudged it (and verified at runtime).

This is my delphi translation

type
{$IFDEF JS_NAN_BOXING}  //WIN32
  JSValue           = UInt64;
{$ELSE} //WIN64
  JSValueUnion = record
      case byte of
      0 : (&int32 : Int32);
      1 : (float64 : Double);
      2 : (Ptr : Pointer);
      3 : (short_big_int : Int32);
  end;

  JSValue = record
    u   : JSValueUnion;
    tag : Int64;
  end;
  //compile time assertion fudge
  const _testJSValue_size = 1 div Ord(SizeOf(JSValue) = 16);

{$ENDIF}

Thanks for the tip about the amalgamation build.

[vincentparrett]

Ok, so this was user error. I read somewhere that the return val of JS_Eval is the module - so was expecting to get a module value back - when in reality it's return undefined in both Win32/64.

I eventually traced my real problem (C function not being called) to the size of enums - in Delphi they will be emitted in as msaller size as possible.

the fix was to set the enum size

type
   {$MINENUMSIZE 4}
  JSCFunctionEnum = (
    JS_CFUNC_generic,
    JS_CFUNC_generic_magic,
    JS_CFUNC_constructor,
    JS_CFUNC_constructor_magic,
    JS_CFUNC_constructor_or_func,
    JS_CFUNC_constructor_or_func_magic,
    JS_CFUNC_f_f,
    JS_CFUNC_f_f_f,
    JS_CFUNC_getter,
    JS_CFUNC_setter,
    JS_CFUNC_getter_magic,
    JS_CFUNC_setter_magic,
    JS_CFUNC_iterator_next
  );
  {$MINENUMSIZE 1}

For some reason on Win32 it worked even with the wrong size enum.