[C] gcc generazione codice senza RIP-relative addressing

[XAlbeX]

void _start (float *i, float *o, float *m)
{
    i[0] = m[0] + 3.0f;
}

Questo codice compilato in questo modo mi da

gcc -O3 -c code.c
objdump -d code.o

code.o:     formato del file elf64-x86-64


Disassemblamento della sezione .text:

0000000000000000 <_start>:
   0:   f3 0f 10 05 00 00 00    movss  0x0(%rip),%xmm0        # 8 <_start+0x8>
   7:   00 
   8:   f3 0f 58 02             addss  (%rdx),%xmm0
   c:   f3 0f 11 07             movss  %xmm0,(%rdi)
  10:   c3                      retq

Come posso evitare che gcc mi generi codice con il "RIP-relative" addressing? (succede soltanto quando nel sorgente c'è un floating-point literal)
Non dovrebbe essere necessario.. si può fare come qui http://stackoverflow.com/questions/6...nline-assembly ?

Mi servirebbe soltanto per rendere il codice "position-independent"

[MItaly]

Scusa, ma il punto di RIP è proprio quello di generare codice position-independent più efficiente... puoi spiegare meglio cosa vuoi ottenere?

[XAlbeX]

Il compilatore mette le costanti literal nella sezione .rodata e quindi rende il codice della funzione dipendente da quella sezione.

Dato che le costanti sono tutte literal mi piacerebbe che il compilatore le mescolasse con il codice eseguibile (come fa con le costanti intere) in modo da poter caricare e spostare facilmente il codice senza dipendere da altre sezioni.

E' fattibile?


EDIT
Vorrei ottenere lo stesso risultato che produce con gli interi

void _start (int *i, int *o, int *m)
{
	i[0] = m[0] + 3;
}

$ gcc -O3 -c code.c
$ objdump -d code.o

code.o:     formato del file elf64-x86-64


Disassemblamento della sezione .text:

0000000000000000 <_start>:
   0:	8b 02                	mov    (%rdx),%eax
   2:	83 c0 03             	add    $0x3,%eax
   5:	89 07                	mov    %eax,(%rdi)
   7:	c3                   	retq

in questo caso la costante 3 è nel codice eseguibile non in un'altra sezione

[MItaly]

Con gli interi si può fare una cosa del genere perché le istruzioni che operano con essi normalmente hanno anche una variante con "immediate value", per cui l'operando viene incorporato direttamente nell'istruzione assembly.
Questo non vale per i literal di altri tipi di dati, come le stringhe e i numeri in virgola mobile, dato che le istruzioni che operano su di essi non prevedono varianti che li incorporino direttamente nell'istruzione assembly; per questo motivo, classicamente vengono piazzati come dici in .rodata (e il RIP-addressing semplifica il lavoro a linker e loader nel momento in cui chiedi che il codice sia position-indipendent).

Ma in ogni caso, per far generare a gcc codice position-indipendent bastano i vari switch -pie/-fpic/..., ma ovviamente l'"indipendenza di posizione" è relativa all'intero binario generato alla fine (ovvero, l'immagine eseguibile si può caricare in memoria a qualunque indirizzo, ma ovviamente deve stare tutta assieme in memoria). Tu invece cosa vuoi fare, generare una funzione che sia completamente autocontenuta? A che scopo?

[XAlbeX]

se non esistono le istruzioni con "immediate value" per i floating-point allora mi accontento di appendere la sezione .rodata alla .text in questa maniera (che per ora sembra funzionare)

OUTPUT_FORMAT(binary)

SECTIONS
{
    merged : 
    {
        *(.text)
        *(.rodata*)
    }

    /DISCARD/ : 
    {
        *(*)
    }
}

Sto facendo per hobby un algoritmo genetico/reti neurali dove le creature sono rappresentate da queste piccole funzioni "completamente autocontenute" che vengono compilate dinamicamente e volevo che contenessero solo l'essenziale (più ce ne stanno in memoria meglio è)

Potrebbero sorgere altri problemi con l'aumentare delle righe di codice visto che ho scartato tutte le altre sezioni? Tieni conto che accedono solo ai 3 puntatori e fanno semplici operazioni + - * / > < tra di loro e costanti literal

[MItaly]

Se scarti .bss e .data non puoi più usare variabili globali.

Comunque, continuo a non capire: che ti importa che i literal stiano da una parte o dall'altra? Lascia che il compilatore faccia il suo lavoro... se vuoi il controllo completo su questi dettagli l'unica è scrivere in assembly.

[XAlbeX]

Comunque, continuo a non capire: che ti importa che i literal stiano da una parte o dall'altra?

Effettivamente niente.. pensavo fosse la soluzione più semplice

Comunque dovrebbe andare bene così. Se deciderò di mettere anche variabili statiche ci aggiungerò anche quelle due sezioni oppure valuterò se farlo con un .so
Grazie

[MItaly]