Script linker: strategie per il debugging?

Question

Sto cercando di eseguire il debug di un problema di linker che ho, durante la scrittura di un kernel.

Il problema è che ho una variabile SCAN_CODE_MAPPING che non sono in grado di utilizzare: sembra vuota o qualcosa del genere. Posso risolvere il problema cambiando il modo in cui collego il mio programma, ma non so perché.

Quando guardo all'interno del file binario generato utilizzando objdump, i dati per la variabile sono sicuramente lì, quindi c'è solo qualcosa di rotto con il riferimento ad esso.

Here's a gist con entrambi gli script del linker e la parte della tabella dei simboli diversa tra i due file.

Ciò che mi confonde è che entrambe le tabelle dei simboli hanno tutti gli stessi simboli, sono della stessa lunghezza e sembrano contenere i dati corretti. L'unica differenza che posso vedere è che non sono nello stesso ordine.

Finora ho provato

• ispezionare la posizione SCAN_CODE_MAPPING di memoria per assicurarsi che ha i dati mi aspetto e non è stato azzerato
• controllando che tutti i simboli sono gli stessi
• controllando che tutti i contenuti di simboli sono la stessa lunghezza
• guardando .data.rel.ro.local per assicurarsi che ha l'indirizzo dei dati

Una possibile indizio è questo avvertimento:

warning: uninitialized space declared in non-BSS section `.text': zeroing

che ricevo sia in rotta e il caso corretto.

Cosa dovrei provare dopo?

Answer 1

È possibile ottenere più informazioni utilizzando "readelf".

In particolare, uno sguardo alle intestazioni di programma:

readelf programma -l

tua sezione BSS è molto diverso da quello standard, che probabilmente causando l'avvertimento. Ecco ciò che il difetto si presenta come sul mio sistema:

.bss   : 
    { 
    *(.dynbss) 
    *(.bss .bss.* .gnu.linkonce.b.*) 
    *(COMMON) 
    /* Align here to ensure that the .bss section occupies space up to 
     _end. Align after .bss to ensure correct alignment even if the 
     .bss section disappears because there are no input sections. 
     FIXME: Why do we need it? When there is no .bss section, we don't 
     pad the .data section. */ 
    . = ALIGN(. != 0 ? 64/8 : 1); 
    } 

Se una sezione di ingresso non corrisponde a nulla nello script del linker, il linker deve ancora metterlo da qualche parte. Assicurati di coprire tutte le sezioni di input.

Si noti che c'è una differenza tra sezioni e segmenti. Le sezioni vengono utilizzate dal linker, ma l'unica cosa che il programma di caricamento esamina sono i segmenti. Il segmento di testo include la sezione di testo, ma include anche altre sezioni. Le sezioni che vanno nello stesso segmento devono essere adiacenti. Quindi l'ordine conta.

La sezione dei rodati di solito segue la sezione di testo. Questi sono entrambi di sola lettura durante l'esecuzione e verranno visualizzati una volta nelle intestazioni del programma come una voce LOAD con leggere le autorizzazioni di esecuzione &. Quella voce CARICA è il segmento di testo.

La sezione bss in genere va dopo la sezione dati. Questi sono entrambi scrivibili durante l'esecuzione e verranno visualizzati una volta nelle intestazioni del programma come una voce LOAD con leggere le autorizzazioni di scrittura &. Quella voce CARICA è il segmento di dati.

Se si modifica l'ordine, influisce sul modo in cui il linker genera le intestazioni del programma. Le intestazioni del programma, piuttosto che le intestazioni di sezione, vengono utilizzate quando si carica il programma prima di eseguirlo. Assicurati di controllare le intestazioni del programma quando usi uno script linker personalizzato.

Se è possibile fornire ulteriori dettagli su quali sono i propri sintomi effettivi, sarà più semplice da aiutare.

Answer 2

Il problema è che stavo scrivendo un sistema operativo, e solo 12k di esso venivano caricati invece dell'intera cosa. Quindi lo script linker funzionava davvero bene.

I principali strumenti che ho usato per comprendere i binari erano:

• nm
• objdump
• readelf