Forum: Compiler & IDEs GCC/GDB Source Lookup Path


von -funsigned-char (Gast)


Lesenswert?

Hi,

stehe vor dem Problem, dass der GDB die Sourcen nicht eindeutig findet, 
da es zB mehrere main.c Dateien in der Projektstruktur gibt, von denen 
natürlich immer nur eine zum aktuell zu debuggendem Programm gehört.

Unser Make System kompiliert die Source Pfade nicht relativ zum 
Projektwurzelverzeichnis, sondern relativ zu Projektunterverzeichnissen.
Dh konkret wird als Parameter src/main.c dem avr-gcc übergeben. 
(zielführender wäre denke ich a/b/src/main.c)

Bevor ich nun die Makeumgebung, die ich nicht geschrieben habe, 
analysiere, möchte ich mal grundsätzlich verstehen, woher der GDB seine 
Informationen zu den Sourcepfaden holt und der avr-gcc sie speichert:

1. Gibt es eine Möglichkeit, aus dem .elf File auszulesen, in welcher 
Form der Pfad der Sourcedateien gespeichert wurde?

2. Hat der (avr-)gcc eine Funktion, um grundsätzlich den absoluten Pfad 
im .elf File abzulegen? Hilfreich wäre auch, den Pfad relativ zum 
Wurzelverzeichnis im .elf File zu hinterlegen.


Danke schonmal für alle Anregungen und Ideen.

von Link zu Artikel (Gast)


Lesenswert?

>GDB die Sourcen nicht eindeutig findet,
>da es zB mehrere main.c Dateien in der Projektstruktur gibt, von denen
>natürlich immer nur eine zum aktuell zu debuggendem Programm gehört.

Wieso ist das ein Problem? Der Pfad zum jeweils verwendeten main.c File 
ist
im .elf hinterlegt, die nicht verwendeten interessieren gar nicht.
Hast Du´s probiert oder sind das Phantomschmerzen?

>1. Gibt es eine Möglichkeit, aus dem .elf File auszulesen, in welcher
>Form der Pfad der Sourcedateien gespeichert wurde?

Einfach

$ strings <elf-file> |grep main

anwenden. Da siehst Du die Pfade irgendwo.

Evtl hilft auch objdump.

Ansonsten:
Der gdb hat Optionen und Kommandos um die Suchpfade bekanntzugeben.
Siehe Manual.

von -funsigned-char (Gast)


Lesenswert?

Hi, danke für die Antwort

Link zu Artikel schrieb:
> Ansonsten:
> Der gdb hat Optionen und Kommandos um die Suchpfade bekanntzugeben.
> Siehe Manual.

Jo, das funktioniert auch gut, erfordert halt für jedes Teilprojekt 
immer etwas Konfiguration, daher wäre es komfortabel, wenn wir es 
kompilieren könnten, so dass der gdb out of-the-box die richtigen 
Dateien findet.

Das Problem tritt tatsächlich auf, es wird für main.c wie für alle 
anderen (auch über Librarys gelinkte Sourcedateien) genau der Pfad 
gespeichert, der bei gcc angegeben wurde. Damit ist die main.c ja nicht 
eindeutig, wenn es im Dateisystem mehrere gibt.

strings funktioniert nicht, jedoch objdump --dwarf.

Ok, dh die einzige Möglichkeit ist nun, den Compiler "weiter oben" im 
Dateisystem mit längeren aufzurufen und es gibt keine Möglichkeit, gcc 
zu sagen, er soll grundsätzlich den absoluten Pfad ablegen?

von -funsigned-char (Gast)


Lesenswert?

-funsigned-char schrieb:
> den Compiler "weiter oben" im Dateisystem mit längeren aufzurufen

soll heißen: den Compiler "weiter oben" im Dateisystem mit längeren 
Pfaden aufzurufen

von Link zu Artikel (Gast)


Lesenswert?

>genau der Pfad
>gespeichert, der bei gcc angegeben wurde.

Soll ja auch so sein?!?!

>Damit ist die main.c ja nicht
>eindeutig, wenn es im Dateisystem mehrere gibt.


Verstehe nicht, was Du willst.
Solange das elf die kompilierte referenziert, ist doch alles ok?

Möglicherweise hängt es davon ab, ob Du den gdb
von innerhalb des "richtigen" Directory-Subtrees startest.
Was hindert Dich dran?

>gcc zu sagen, er soll grundsätzlich den absoluten Pfad ablegen?

Es gibt verschiedene Varianten von -g-Optionen, vielleicht tut das
eine davon.
Auch für den gcc gibt es ein Manual.

Wenn Du absolute Pfade willst, kannst Du die ja nach Deiner
oben zitierten Aussage auf der Kommandozeile so angeben...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.