Closed Bug 530018 Opened 12 years ago Closed 11 years ago

js_DecompileToString Undefined symbol


(Core :: JavaScript Engine, defect)

Not set





(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)


(Whiteboard: fixed-in-tracemonkey)


(2 files)

/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/  -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
Attached patch patchSplinter Review
Assignee: general → ginn.chen
Attachment #413537 - Flags: review?(brendan)
Comment on attachment 413537 [details] [diff] [review]

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?

Attachment #413537 - Flags: review?(brendan) → review?(jim)
This is similar to bug 429105.
I think the reason is the same. JSBool (*decompiler)(JSPrinter *jp) is a c++ function pointer.
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?
I was reading the examples here:

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.
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?
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.
Attached patch sample patchSplinter Review
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.
Attachment #413975 - Flags: review+
Attachment #413537 - Flags: review?(jim) → review-
Whiteboard: fixed-in-tracemonkey
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.