2012-05-09 4 views
10

Ich habe einige Qt-Code mit googles nacl Compiler kompiliert, aber der ncval-Validator nicht grok es. Ein Beispiel unter vielen:ungerade kompilierten Code

src/corelib/animation/qabstractanimation.cpp:165 

Hier ist der entsprechende Code:

#define Q_GLOBAL_STATIC(TYPE, NAME)         \ 
    static TYPE *NAME()            \ 
    {                \ 
     static TYPE thisVariable;         \ 
     static QGlobalStatic<TYPE > thisGlobalStatic(&thisVariable); \ 
     return thisGlobalStatic.pointer;        \ 
    } 

#ifndef QT_NO_THREAD 
Q_GLOBAL_STATIC(QThreadStorage<QUnifiedTimer *>, unifiedTimer) 
#endif 

, die kompiliert:

00000480 <_ZL12unifiedTimerv>: 
    480:  55      push %ebp 
    481:  89 e5     mov %esp,%ebp 
    483:  57      push %edi 
    484:  56      push %esi 
    485:  53      push %ebx 
    486:  83 ec 2c    sub $0x2c,%esp 
    489:  c7 04 24 28 00 2e 10 movl $0x102e0028,(%esp) 
    490:  8d 74 26 00    lea 0x0(%esi,%eiz,1),%esi 
    494:  8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi 
    49b:  e8 fc ff ff ff   call 49c <_ZL12unifiedTimerv+0x1c> 
    4a0:  84 c0     test %al,%al 
    4a2:  74 1c     je  4c0 <_ZL12unifiedTimerv+0x40> 
    4a4:  0f b6 05 2c 00 2e 10 movzbl 0x102e002c,%eax 
    4ab:  83 f0 01    xor $0x1,%eax 
    4ae:  84 c0     test %al,%al 
    4b0:  74 0e     je  4c0 <_ZL12unifiedTimerv+0x40> 
    4b2:  b8 01 00 00 00   mov $0x1,%eax 
    4b7:  eb 27     jmp 4e0 <_ZL12unifiedTimerv+0x60> 
    4b9:  8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi 
    4c0:  b8 00 00 00 00   mov $0x0,%eax 
    4c5:  eb 19     jmp 4e0 <_ZL12unifiedTimerv+0x60> 
    4c7:  90      nop 
    4c8:  90      nop 
    4c9:  90      nop 
    4ca:  90      nop 
    4cb:  90      nop 

Überprüfen Sie den Aufrufbefehl an 49b: es ist das, was der Prüfer kann nicht grok. Was in aller Welt könnte den Compiler veranlassen, eine Anweisung zu geben, die in die Mitte von sich selbst aufruft? Gibt es einen Weg dahin? Ich habe mit -g -O0 -fno-inline kompiliert. Compilerfehler?

+0

Wie auch immer, ich gebe auf und warte auf eine bessere Toolchain. Sie haben tolle Antworten geliefert. Vielen Dank! – user1095108

Antwort

3

Vermutlich ist es ein Aufruf eines externen Symbols, das zur Verbindungszeit ausgefüllt wird. Eigentlich wird externalSymbol-4 aufgerufen, was etwas merkwürdig ist - vielleicht wirft das den ncval-Validator aus dem Geruch.

+0

Es ist. Gibt es einen Weg dahin ... Ahhh sag es mir nicht, verbinde alles statisch? – user1095108

+1

Versuchen Sie, 'PIC' auszuschalten, wodurch die Umlagerungen verschoben werden, um die Ladezeit zu verketten. Beachten Sie, dass dadurch viele der Gründe zunichte gemacht werden, die zu einer dynamischen Verknüpfung führen würden. –

+0

Kann man so verlinken und nicht abstürzen? Würde es sich lohnen zu versuchen? – user1095108

1

Ist dies eine dynamische Bibliothek oder ein statisches Objekt, das noch nicht mit einer ausführbaren Datei verknüpft ist?

In einer dynamischen Bibliothek kam dies wahrscheinlich heraus, weil der Code als positionsabhängig erstellt und in eine dynamische Bibliothek eingebunden wurde. Versuchen Sie "objdump -d -r-R" darauf, wenn Sie TEXTREL sehen, das ist der Fall. TEXTREL wird nicht in dynamischen Verknüpfungsgeschichten von NaCl unterstützt. (gelöst durch -fPIC-Flag während der Kompilierung des Codes)

Mit einem statischen Objekt versuchen Sie zu validieren, nachdem es in eine statische ausführbare Datei verknüpft wurde.