530018 - js_DecompileToString Undefined symbol

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Ginn Chen]

/opt/SUNWspro/bin/CC -o js -I/usr/X11/include -xlibmieee -xbuiltin=%all -features=tmplife -norunpath -mt  -DDEBUG -D_DEBUG -DDEBUG_ginn -DTRACING -g -features=extensions -D__FUNCTION__=__func__  js.o   -L../../../dist/lib -ljemalloc -lpthread -M /usr/lib/ld/map.noexstk -xildoff -z lazyload -z combreloc  -z ignore -R '$ORIGIN:$ORIGIN/..'         -M ../../../../js/src/config/solaris_ia32.map  -L../../../dist/bin -L../../../dist/lib -L/export/home/ginn/field/mozilla-central/debug/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lposix4 ../editline/libeditline.a ../libjs_static.a -lsocket -ldl -lm -lCrun -lCstd     
Undefined			first referenced
 symbol  			    in file
js_DecompileToString                ../libjs_static.a(jsapi.o)
ld: fatal: symbol referencing errors. No output written to js

Comment 1

[Ginn Chen]

Attachment: patch

Comment 2

[Brendan Eich [:brendan]]

Comment on attachment 413537 [details] [diff] [review]
patch

Ducking -- doesn't jsopcode.h declare js_DecompileToString within an extern "C" block?

What's the bug here, are we not following C or C++ specs?

/be

Comment 3

[Leon Sha]

This is similar to bug 429105.
https://bugzilla.mozilla.org/show_bug.cgi?id=429105#c18
I think the reason is the same. JSBool (*decompiler)(JSPrinter *jp) is a c++ function pointer.

Comment 4

[Jim Blandy :jimb]

The declaration of js_DecompileToString in jsopcodes.h is extern "C".  That declaration is visible to all uses.  Why isn't the 'decompiler' argument taken to be a "C" function pointer?

Comment 5

[Jim Blandy :jimb]

I was reading the examples here:
http://docs.sun.com/source/819-3689/Ch3.Std.html

In particular, the "composer" function is declared like this: 

extern "C" void composer( int(*)(int) );

and is said to expect a function with C linkage.  If that's the case, then it seems to me that js_DecompileToString's argument should be a function with C linkage, as well.  The only functions ever passed to js_DecompileToString are js_DecompileFunctionBody and js_DecompileFunction, both of which are declared within the same extern "C" block tha js_DecompileToString is.

I'm inclined to replace the function pointer argument to js_DecompileToString with a boolean flag named 'bodyonly' that simply chooses either js_DecompileFunctionBody or js_DecompileFunction.

Comment 6

[Jim Blandy :jimb]

Leon or Ginn, can you explain why the compiler doesn't seem to be treating js_DecompileToString the way the documentation I linked to suggests it should?

Comment 7

[Leon Sha]

This is the warning message for jsopcode.cpp.
"jsopcode.cpp", line 4911: Warning: function JSString*(JSContext*,const char*,JSFunction*,unsigned,int,int,int,int(*)(JSPrinter*)) overloads extern "C" JSString*(JSContext*,const char*,JSFunction*,unsigned,int,int,int,extern "C" int(*)(JSPrinter*)) because of different language linkages.
For js_DecompileToString function in jsopcode.h, both js_DecompileToString and JSBool (*decompiler)(JSPrinter *jp) are inside extern "C" and have c linkage. But in jsopcode.cpp, the JSBool (*decompiler)(JSPrinter *jp) is not inside extern "C". That means this decompiler has c++ linkage. That make the overloads warning happened. If the function point in jsopcode.cpp has c linkage, this kind of warning will not happen. Attached patch is another solution based on this theory.

Comment 8

[Leon Sha]

Attachment: sample patch

Comment 9

[Jim Blandy :jimb]

I see --- because the definition in jsopcodes.cpp is not in extern "C", its argument gets a C++ linkage function type, and it is seen as an overloading of the function declared in jsopcodes.h.

I like the typedef solution.  The type should be named JSDecompilerPtr.  r=me with that change.

Comment 10

[Leon Sha]

http://hg.mozilla.org/tracemonkey/rev/94398118b5ec