2012-05-09 18 views
10

Ho compilato un codice Qt con il compilatore nacl di google, ma il validatore ncval non lo elimina. Un esempio tra i tanti:codice compilato dispari

src/corelib/animation/qabstractanimation.cpp:165 

Ecco il codice rilevante:

#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 

che compila a:

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 

Verificare l'istruzione di chiamata a 49b: è ciò che il validatore non può Grok. Cosa diavolo potrebbe indurre il compilatore a emettere un'istruzione che chiama nel mezzo di se stessa? C'è un modo per aggirare questo? Ho compilato con -g -O0 -fno-inline. Bug del compilatore?

+0

In ogni caso, mi sto arrendendo e aspetto una migliore toolchain. Hai fornito risposte fantastiche. Grazie! – user1095108

risposta

3

Presumibilmente è davvero una chiamata a un simbolo esterno, che verrà compilato al momento del collegamento. In realtà ciò che verrà chiamato è externalSymbol-4, che è un po 'strano - forse questo è ciò che sta lanciando il validatore ncval dal profumo.

+0

Lo è. C'è un modo per aggirarlo ... Ahhh non dirmelo, collega tutto staticamente? – user1095108

+1

Prova a disattivare il 'PIC' che sposta le delocalizzazioni per collegare il tempo dal caricamento. Si noti che questo annulla molte delle ragioni che potrebbero causare il collegamento dinamico in primo luogo. –

+0

È possibile collegarsi in questo modo e non bloccarsi? Vorresti provare a crederci? – user1095108

1

È una libreria dinamica o un oggetto statico che non è ancora collegato a un eseguibile?

In una libreria dinamica questo probabilmente è venuto fuori perché il codice è stato creato come dipendente dalla posizione e collegato in una libreria dinamica. Prova "objdump -d -r -R" su di esso, se vedi TEXTREL, questo è il caso. TEXTREL non è supportato nelle storie di collegamento dinamico di NaCl. (risolto con flag -fPIC durante la compilazione del codice)

Con un oggetto statico provare a convalidare dopo essere stato collegato a un eseguibile statico.

Problemi correlati