Hi all, We've finally managed to overcome the "unexpected declaration..." error. As turned out, it was caused by a bug in our vendor's gcc compiler. In short, it generates broken code when function inlining is enabled.
There is a subtle problem that prevents us to workaround the gcc bug by just turning the "-fno-inline" compiler switch on. Namely, there are the following defines in global.h: #define INLINE(header) inline header __attribute__((always_inline)) The problem is that there is no way to disable the "__attribute__((always_inline))" pragma externally (that is, without code modifications). Regardless to our case, I think sometimes it might be helpful to disable inline at all. So why not define the pragma conditionally, e.g.: #if !defined(DISABLE_INLINE) #define INLINE(header) inline header __attribute__((always_inline)) #else #define INLINE(header) inline header #endif I think such a modification would be quite harmless and somewhat helpful. On Apr 29, 5:48 pm, Kevin Millikin <[email protected]> wrote: > Hi Evgeny, > > In the full codegen, the current context is kept in a dedicated register. > > Contexts form a linked list with the global context at the tail. The > intermediate contexts are either function contexts corresponding a > function's scope or with contexts corresponding to a with scope. There is a > field in every context pointing to the enclosing function context---and for > function contexts this field should point to the function context itself. > > The assert is firing when we try to generate code to initialize a function > (or const) that has to go in the context, because it is possibly referenced > from some inner scope. The assert checks that we don't try to do this with > a 'with' or 'global' context, by checking that the value in the context > register and that context's function context are identical. > > So, my guess is that the context chain is messed up somehow. Perhaps you do > have a function context, but its enclosing function context has not been > initialized to properly point to itself. Context initialization happens in > the runtime function (which is platform independent) and also possibly in a > platform-specific 'FastNewContext' stub. I'm not sure if this stub is > implemented for MIPS, but if it is, I'd look there first to make sure it's > properly initializing the new context and returning the proper context. > > ;; Kevin > > On Fri, Apr 29, 2011 at 12:05 PM, Evgeny Baskakov <[email protected] > > > > > > > > > wrote: > > Hi all, > > > I just started using the MIPS port of V8. So far I'm using the 'shell' > > program to run JS code. Everything works fine unless the '--debug- > > code' switch is enabled. With the switch, an "unexpected declaration > > in current context" error error pops out (the full message text is > > below). > > > A brief evaluation revealed that it only happens when a nested JS > > function accesses a variable that is defined in the enclosing function > > body. For instance, when the nested function SetupArray.getFunction() > > accesses the SetupArray.specialFunctions variable, in src/array.js. > > > I do realize that the MIPS port is out of the official scope, but the > > full-codegen part (which pops out the error) is very similar in all V8 > > ports. So could someone point out what the reason could be? What > > should be checked fist? > > > Thanks. > > > -- > > > And here goes the full error message text: > > > abort: Unexpected declaration in current context. > > > ==== Stack trace ============================================ > > > Security context: 0x2caa8991 <JS Object>#0# > > 1: SetupArray [native array.js:1180] (this=0x2caa9391 <JS > > Object>#1#) > > 2: /* anonymous */ [native array.js:1249] (this=0x2caa9391 <JS > > Object>#1#) > > > ==== Details ================================================ > > > [1]: SetupArray [native array.js:1180] (this=0x2caa9391 <JS > > Object>#1#) { > > // stack-allocated locals > > var getFunction = 0x2cae8061 <undefined> > > // heap-allocated locals > > var a = 0x2cae8061 <undefined> > > // expression stack (top to bottom) > > [03] : 0 > > [02] : 0 > > [01] : 3301874 > > --------- s o u r c e c o d e --------- > > function SetupArray(){???%SetProperty($Array.prototype,"constructor", > > $Array,2);???InstallFunctions($Array, > > 2,$Array(?"isArray",ArrayIsArray?));??var a= > > %SpecialArrayFunctions({});??function getFunction(b,c,d){?var g=c;? > > if(a.hasOwnProperty(b)){?g=a[b];?}?if(!(typeof(d)==='undefined')){? > > %FunctionSetLength(g,d);?}?return g... > > > ----------------------------------------- > > } > > > [2]: /* anonymous */ [native array.js:1249] (this=0x2caa9391 <JS > > Object>#1#) { > > // stack-allocated locals > > var .result = 0x2cae8061 <undefined> > > // expression stack (top to bottom) > > [01] : 0x2caa9391 <JS Object>#1# > > --------- s o u r c e c o d e --------- > > ???????????????????????????????????var visited_arrays=new > > InternalArray();?????function GetSortedArrayKeys(a,b){?var c=b.length;? > > var d=[];?for(var e=0;e<c;e++){?var f=b[e];?if(f<0){?var g=-1-f;?var > > h=g+b[++e];?for(;g<h;g++){?var i=a[g];?if(!(typeof(i)==='undefined')|| > > g in a){?d.push(g);?}?}?}else{??... > > > ----------------------------------------- > > } > > > ==== Key ============================================ > > > #0# 0x2caa8991: 0x2caa8991 <JS Object> > > #1# 0x2caa9391: 0x2caa9391 <JS Object> > > ===================== > > > Aborted > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
