Re: CPU Auswahl beim Uebersetzen

Marc Santhoff <M.Santhoff(at)t-online.de> wrote:
> Ein Programm lädt (unter anderem) die GTK-Bibliothek und verabschiedet
> sich unter noch nicht ganz klaren Umständen mit Signal 4 (Illegal
> Instruction).

Ist das reproduzierbar, d.h. tritt es immer an derselben
Stelle auf? Wenn es variiert, könnte es ein Hardware-Pro-
blem (hauptsächlich RAM) bedeuten.

Aber auch, wenn es nicht variiert, kann es ein Hardware-
Problem sein, z.B. ein gekipptes Bit in der Library auf
der Festplatte.

Eine dritte Möglichkeit wäre, daß es sich um einen obskuren
Bug in der Library handelt (z.B. eine Art Buffer-Overflow),
der dazu führt, daß im Code irgendwo ein Byte überschrieben
wird. Also ähnlich, wie dies bei manchen Exploits gezielt
versucht wird.

> Ich bin aber sicher, daß dieses Programm auf allen i386ern
> laufen kann und keine Sonderbefehle der neueren CPU-Modelle benutzt.
>
> Ein core-dump sagt mir, daß der Fehler in einer Funktion in der GTK-lib
> auftritt. Die ist aber mit ziemlicher Sicherheit mit einer make.conf
> Übersetzt worden, in der kein CPU-Typ bestimmt ist.
>
> Meine Frage nun: Wie arbeitet gcc auf einem FreeBSD(4), wenn man in
> make.conf nichts weiter angibt, ich hatte angenommen, daß dann ebenfalls
> alle i386er CPUs untzerstützt werden...

Das ist korrekt.

> Ganz ausschließen kann ich nicht, daß diese Bibliothek aus einem Package
> stammt, also nicht klar ist, wie sie erstellt wurde. Natürlich wird sie
> neu gebaut und gestested, aber trotzdem: Ist meine Annahme richtig, das
> eine ohne CPU-Deklartation übersetzte Bibliothek oder ein Programm auf
> allen Unterstützten CPUs laufen sollte, ohne ungültige Maschinencodes zu
> benutzen?

Ja, die Annahme ist richtig. Der Code wird zwar für den
jeweiligen CPU-Typ optimiert, d.h. er läuft möglicherweise
auf anderen Prozessoren ineffizient, aber er _sollte_ auf
allen CPU-Typen prinzipiell laufen.

Im Zweifelsfall kannst Du »NO_CPU_CFLAGS=true« in Deine
/etc/make.conf schreiben, um auch diese Optimierung noch
auszuschalten. Du mußt dann natürlich alles betreffende
neu compilieren, vor allem auch die Libraries. Aber ich
glaube eigentlich nicht daran, daß das die wirkliche Ur-
sache des Problems ist.

Ein Neucompilieren könnte das Problem natürlich trotzdem
beheben, weil die Library dann an einer anderen Stelle der
Festplatte landet (falls es an der Festplatte liegt), oder
weil durch geänderte Optimierungen andere Code-Pfade ent-
stehen, so daß sich ein Overflow-Bug nicht mehr in dieser
Form bemerkbar macht (falls es ein solcher Bug ist).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"And believe me, as a C++ programmer, I don't hesitate to question
the decisions of language designers.  After a decent amount of C++
exposure, Python's flaws seem ridiculously small." -- Ville Vainio
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message