odd compiled code

Question

I've compiled some Qt code with google's nacl compiler, but the ncval validator does not grok it. One example among many:

src/corelib/animation/qabstractanimation.cpp:165

Here's the relevant 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

which compiles to:

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

Check the call instruction at 49b: it is what the validator cannot grok. What on earth could induce the compiler to issue an instruction that calls into the middle of itself? Is there a way around this? I've compiled with -g -O0 -fno-inline. Compiler bug?

Anyway, I'm giving up and waiting for a better toolchain. You've provided awesome answers. Thanks! — user1095108, May 09 '12 at 20:34

score 3 · Accepted Answer · answered May 09 '12 at 19:56

3

Presumably it's really a call to an external symbol, which will get filled in at link time. Actually what will get called is externalSymbol-4, which is a bit strange -- perhaps this is what is throwing the ncval validator off the scent.

answered May 09 '12 at 19:56

TonyK

16,761
4
37
72

It is. Is there a way around it... Ahhh don't tell me, link everything statically? – user1095108 May 09 '12 at 20:01
1

Try turning off `PIC` which moves the relocations to link time from load time. Note that this nullifies many of the reasons that would cause you to dynamically link in the first place. – Mark B May 09 '12 at 20:02
Is it possible to link like that and not crash? Would trying -fpic be worthwhile? – user1095108 May 09 '12 at 20:12
Hold on -- you said that it *compiles* to that machine code. Now you're saying that it *links* to it? What stage of the compile-link-load-run process are we seeing? – TonyK May 09 '12 at 20:14
@user1095108 The loader know that in `PIC` mode, certain relocations (the calls) need to happen at runtime, before the app starts. If you turn off `PIC` then the relocations will happen at link time when your binary is produced. – Mark B May 09 '12 at 20:17
I meant, is it possible to link to such a library (compiled without -fPIC) and not crash. You are seeing the disassembly of a shared library (.so file). The .nexe that links to this library is evaluated as "safe". – user1095108 May 09 '12 at 20:19
If you consistently compiled without `-fPIC` then if it's crashing that would indicate a software bug somewhere in the codebase. It should work fine. – Mark B May 09 '12 at 20:22
I'd love to execute the .nexe that links to the QtCore library, but the validator won't allow it. There's a way to override the validator, but I can't, since I compiled 32-bit and my machine is 64-bit. I'd have to do it in a virtual machine. – user1095108 May 09 '12 at 20:28

score 1 · Answer 2 · answered May 18 '12 at 09:21

Is this a dynamic library or a static object that is not linked to an executable yet?

In a dynamic library this likely came out because the code was built as position-dependent and linked into a dynamic library. Try "objdump -d -r -R" on it, if you see TEXTREL, that is the case. TEXTREL is not supported in NaCl dynamic linking stories. (solved by having -fPIC flag during compilation of the code)

With a static object try to validate after it was linked into a static executable.

odd compiled code

2 Answers2