código compilado impar

He compilado algún código Qt con el compilador nacl de Google, pero el validador ncval no lo compila. Un ejemplo entre muchos:código compilado impar

src/corelib/animation/qabstractanimation.cpp:165

Aquí está el código correspondiente:

#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

que 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

Comprobar la instrucción de llamada al 49b: es lo que el validador no puede grok. ¿Qué podría inducir al compilador a emitir una instrucción que llame al medio de sí mismo? ¿Hay alguna forma de evitar esto? He compilado con -g -O0 -fno-inline. ¿Error del compilador?

Fuente

2012-05-09 user1095108

De todos modos, me estoy dando por vencido y esperando una mejor cadena de herramientas. Has proporcionado respuestas increíbles. ¡Gracias! – user1095108

Presumiblemente, se trata de una llamada a un símbolo externo, que se completará en el momento del enlace. En realidad, lo que se llamará es externalSymbol-4, que es un poco extraño, quizás esto es lo que está arrojando al validador ncval del olor.

Fuente

2012-05-09 19:56:48 TonyK

Lo es. ¿Hay alguna forma de evitarlo? Ahhh, no me digas, ¿vinculas todo estáticamente? – user1095108

Intente apagar 'PIC', que mueve las reubicaciones para vincular el tiempo de carga. Tenga en cuenta que esto anula muchas de las razones que le causarían vincular dinámicamente en primer lugar. –

¿Es posible vincular de esa manera y no bloquear? ¿El intentar -fpic valdría la pena? – user1095108

¿Se trata de una biblioteca dinámica o un objeto estático que aún no está vinculado a un ejecutable?

En una biblioteca dinámica esto probablemente salió porque el código se construyó como dependiente de la posición y se vinculó a una biblioteca dinámica. Pruebe con "objdump -d -r -R" en él, si ve TEXTREL, ese es el caso. TEXTREL no es compatible con las historias de enlace dinámico de NaCl. (resuelto al tener el indicador -FPIC durante la compilación del código)

Con un objeto estático, intente validar después de haberlo vinculado a un archivo ejecutable estático.

Fuente

2012-05-18 09:21:01

Respuesta

Cuestiones relacionadas