GCC generiert nutzlose Anweisungen?

Question

BOOL32 doStuff() { 
    return TRUE; 
} 

gcc 2.95 für VxWorks 5.x, den obigen Code mit -O0 für 32-Bit-x86-Kompilierung folgenden Code erzeugt:

  doStuff: 
0e9de190: push %ebp 
0e9de191: mov  %esp,%ebp 
308   return TRUE; 
0e9de193: mov  $0x1,%eax 
0e9de198: jmp  0xe9de1a0 <doStuff+16> 
312  { 
0e9de19a: lea  0x0(%esi),%esi 
// The JMP jumps here 
0e9de1a0: mov  %ebp,%esp 
0e9de1a2: pop  %ebp 
0e9de1a3: ret 

Alles sieht bis zum JMP und LEA Anweisung normal. Wofür sind sie?

---

Meine Vermutung ist, dass es eine Art von Ausrichtung ist, aber ich bin mir nicht sicher darüber.

Ich würde so etwas getan haben:

  doStuff: 
0e9de190: push %ebp 
0e9de191: mov  %esp,%ebp 
308   return TRUE; 
0e9de193: mov  $0x1,%eax 
0e9de1XX: mov  %ebp,%esp 
0e9de1XX: pop  %ebp 
0e9de1XX: ret 
0e9de1XX: fill with lea 0x0, %esi 

Answer 1

lea 0x0(%esi),%esi ist ein langer NOP und der JMP über sie springt. Sie haben wahrscheinlich eine alte Version von binutils (enthält as), um mit Ihrer alten GCC-Version zu gehen.

Also wenn gcc eine .p2align setzen, um eine Marke in der Mitte der Funktion auszurichten, die sonst kein Verzweigungsziel ist (aus irgendeinem seltsamen Grund, aber es ist -O0, damit es nicht einmal guter Code sein soll), der Assembler machte ein langes NOP und sprang darüber hinweg.

Normalerweise würden Sie nur einen Block von NOPs überspringen, wenn es viele davon gäbe, besonders wenn es sich um Single-Byte-NOPs handelte. Das ist wirklich ein dummer Code, also hör auf so krustige Werkzeuge zu benutzen. Sie könnten versuchen, Ihren Assembler zu aktualisieren (aber immer noch gcc2.95 verwenden, wenn Sie müssen). Oder überprüfen Sie, ob es nicht bei -O2 oder -O3 passiert, in diesem Fall spielt es keine Rolle.

Wenn Sie aus irgendeinem Grund weiterhin gcc2.95 verwenden müssen, dann seien Sie sich bewusst, dass es uralt ist, und dies ist Teil des Kompromisses, den Sie machen, um das zu verwenden, was Sie dazu zwingt, es zu benutzen.