libbfd.a und debuggen

Ich habe für FreeBSD einen eigenständigen Port für eine libbfd.a
gemacht, der eine ,,vollständige'' Lib baut und installiert.

% ls -l /usr/local/lib/libbfd.a
-rw-r--r--  1 root  wheel  4236100 Dec 27 23:40
/usr/local/lib/libbfd.a

Die ist nicht ganz ohne, da sie ja praktisch jedes noch so verquere
Objektformat dieser Welt lesen und verarbeiten kann.

Laut Theodore Roth genügt es aber, die hostbezogene libbfd.a zu haben
(sofern der Host ELF als native object format benutzt), da nur die
Basisfunktionen zum Lesen einer ELF-Datei daraus genutzt werden.  Das
habe ich selbst nicht probiert, aber eigentlich sollte jede der drei
von dir genannten Bibliotheken dies tun können.  Da die binutils
standardmäßig nicht davon ausgehen, dass es eine installierte Version
davon gibt (obwohl dies auf Linuxen üblich zu sein scheint),
compiliert typischerweise jedes binutils-Projekt (GDB vs. generische
binutils) seine eigene Version und linkt statisch gegen diese.

@Jörg

Was meinst Du mit: "(GDB vs. generische binutils)" ?

Mich wundert da, dass es nicht zu Inkompatibilitäten kommt zwischen den
einzelnen libbfd-Versionen die da bei binutils und gdb mitgeliefert
werden.

Eine andere Frage:
Im avr-libc-user-manual-1.2.0 wird immer noch die gdb-Version 6.0
empfohlen. Wenn ich jetzt die neueste Version 6.3 verwende, gibt es da
bezüglich der Versionen für simulavr(xx) bzw. AVaRice Einschränkungen?

Gibt es vielleicht schon eine andere Versionskombinations-Empfehlung
der einzelnen Toolchain-Programme

lt. avr-libc-user-manual-1.2.0:
Binutils 2.14 - gcc 3.3.1 - libc 1.0 - gdb 6.0 - AVaRice 2.0

> Was meinst Du mit: "(GDB vs. generische binutils)" ?

Obwohl der GDB innerhalb der binutils compiliert wird, ist es ein
separates Projekt, sodass üblicherweise eine separate Compilation
benutzt wird (die aber einiges an Quellcode mit den Standard-binutils
gemeinsam nutzt).

Standard-binutils, das ist der Software-Teil, in dessen Rahmen der
Assembler, Linker, Archivar, nm, size etc. gebaut werden.

> Mich wundert da, dass es nicht zu Inkompatibilitäten kommt ...

Die sind doch allesamt statisch in die jeweiligen Tools gelinkt.
Damit kollidiert das nicht mit einer eventuell vorhandenen
systemweiten libbfd.a.  (Eine libbfd.so sollte man meiner Meinung nach
aber besser nicht haben, das wäre eine potenzielle Quelle für
Versionskonflikte.)

> Im avr-libc-user-manual-1.2.0 wird immer noch die gdb-Version 6.0
> empfohlen.

Oh, war mir gar nicht bewusst, dass da konkrete Versionsnummern drin
stehen.  Nö, es ist OK, die jeweils neuesten Releases der einzelnen
Tools zu nehmen.  Ohne jetzt nachzugucken wären das wohl:

. binutils 2.16
. gcc 3.4.2 (oder 3.4.3?)
. avr-libc 1.2.0
. gdb 6.3
. avarice 2.3 (hier musste ich wirklich nachgucken gehen)

Du kannst ja mal einen Bugreport einreichen, dass die Dokumentation
entweder häufiger angepasst werden sollte oder aber allgemeiner
gehalten.  (Ich denke, wir werden uns für letzteres entscheiden.)
Bitte nenne auch die Stelle(n), wo du das gefunden hast.

Ich habe die expliziten Versionsnummern aus der Doku soeben entfernt.
Die Empfehlung ist jetzt, die jeweil letzte freigegebene Version eines
jeden Tools zu nehmen.