Come ottenere gdb su Linux per trovare il file di origine per il cross binario compilato su Windows

Question

sto cercando di eseguire il debug di un'applicazione che è cross-compilato su un host di Windows per un target Linux.

Il problema: Poiché la compilazione iniziale è in Windows, i percorsi del file di origine memorizzati nel file binario hanno il formato C:\Users\foo\project\.... Sul target Linux ho messo i file sorgente sotto \home\foo\project\.... Per impostazione predefinita gdb non trova il file sorgente a causa del diverso percorso.

Quello che ho provato finora:

1. Usa "directory" comando gdb che invia un percorso esatto per il file sorgente .c nel sistema Linux di destinazione in cui si esegue il debug l'applicazione. Questo funziona ma sfortunatamente ci sono letteralmente centinaia di file quindi questa soluzione non è realistica.

2. Utilizzare il comando set substitute-path C:\\Users\\foo\\project /home/foo/project avere gdb sostituto tutti i prefissi. Notare che lo \\ sembra necessario in modo che show substitute-path registri la stringa corretta. Questo purtroppo non funziona. La mia ipotesi è che il comando del percorso sostitutivo non gestisca i percorsi in stile ms-dos.

3. provato che separa le informazioni di debug fuori in un file .debug separato (vedi How to generate gcc debug symbol outside the build target?) e quindi utilizzando debugedit per modificare i percorsi con il comando debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug. Purtroppo anche questo non funziona. debugedit sembra funzionare bene se il percorso esistente è tutto simile a UNIX/Linux ma sembra non funzionare con i percorsi di stile ms-dos.

Ho guardato intorno StackOverflow e mentre ci sono argomenti simili non riesco a trovare nulla che mi aiuterà. Gradirei davvero qualche suggerimento/aiuto. Mi rendo conto che compilare cross da Windows è un modo molto approssimativo, ma non posso evitarlo per il momento.

Grazie

Answer 1

Anche se è un po 'vecchia domanda, ho fatto incontrato lo stesso problema. Sono riuscito a risolverlo ma usando sed su eseguibile binario ... (sì, un 'bit' hack-ish, ma non ho trovato un altro modo). Con sed sono riuscito a sostituire i percorsi dei simboli all'interno dell'eseguibile, il trucco è che la lunghezza del nuovo percorso dovrebbe essere la stessa di quella vecchia.

sed -i "s#C:/srcpath#/srcpath/.#g" ./executable 

Assicurarsi di fare il nuovo percorso della stessa lunghezza, altrimenti il ​​freno volontà eseguibile.

Answer 2

ho anche avere lo stesso problema. L'opzione 1 non è così male come si pensa, perché è possibile creare script di creare tutti i 'directory' comandi con qualcosa di simile a questo codice python:

def get_directory_paths(): 
    return_array = list() 
    unix_path = os.path.join('my','unix','path') 
    for root, dirs, files in os.walk(unix_path): 
     for dir in dirs: 
      full_unix_path = os.path.join(root,dir) 
      escaped_unix_path = re.sub("\s", "\\\\ ", full_unix_path) 
      return_array.insert(0, "directory " + escaped_unix_path) 
    return '\n'.join(return_array) 

Il rovescio della medaglia è che, se si dispone di due file di origine con lo stesso nome in diverse directory, non credo che gcc possa scegliere quello giusto. Questo mi preoccupa, ma nella mia situazione particolare, penso di essere al sicuro.

Per l'opzione 2 (che ho il sospetto che sarebbe fissare la condizione di aliasing da # 1), penso che il problema è che le sostituzioni non sono che termina con un "separatore di file", secondo il linux in modo che non vengono applicate:

Per evitare risultati di sostituzione imprevisti, viene applicata una regola solo se la parte del nome della directory termina con un separatore di directory. Ad esempio, una regola che sostituisce/usr/source in/mnt/cross verrà applicata a /usr/source/foo-1.0 ma non a /usr/sourceware/foo-2.0. E poiché la sostituzione è applicata solo all'inizio del nome della directory, non viene applicata questa regola /root/usr/source/baz.c sia."(Da https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html#index-set-substitute_002dpath)

Non ho provato qualcosa come il tuo # 3 e ho anche considerato qualcosa come @dragn suggerimento, ma nella mia situazione i percorsi non sono nemmeno vicini alla stessa lunghezza, quindi sarà un problema

Penso di essere bloccato con # 1 e uno script, ma se qualcuno ha altri suggerimenti, sono le opzioni interessati :-)