Tschüs,
Jens.
> Was ist der Sinn des Programms "strip"?
Es entfernt die Debugging-Information aus einem Programm.
> Jemand hat mir gesagt, wenn man die Symbole aus einem Programm
> strippt, läuft das Programm schneller.
Auf den allermeisten UNIX-ähnlichen Plattformen läuft ein Programm
nach 'strip' weder schneller, noch wird es schneller geladen.
> Was ist der Sinn des Programms "strip"?
> Jemand hat mir gesagt, wenn man die Symbole aus einem Programm strippt,
> läuft das Programm schneller. Aber welche Symbole kann man entfernen? 
> Alle oder nur die Debug-Symbole?
AFAIK nur die Debug Symbole. Die anderen sollten ja noch gebraucht
werden.
Schneller läuft das Programm nur insofern, als das das binary kleiner
wird und dadurch schneller geladen werden kann.
 
> Warum sind die Symbole überhaupt erst drin, wenn man sie wieder
> entfernen kann? Die Manpage verrät über den Sinn & Zweck nur sehr wenig.
Na zum Debuggen. Aber bei einer gscheiten Distribution sollten die
binaries alle gestripped sein. file gibt Auskunft darüber.
-- 
Wenn das Leben eine Frage ist, ist dann der Tod die Antwort darauf?
> Na zum Debuggen. Aber bei einer gscheiten Distribution sollten die
> binaries alle gestripped sein. file gibt Auskunft darüber.
Oder auch nicht.
Ungestrippte Programme haben den Vorteil das sie halt nicht nur ein 
segmentation fault auswerfen sondern weitere Informationen (im Ideal 
eine Zeilennummer).
Deshalb bevorzuge ich auf der lokalen Platte ungestrippte Programme.
Der Geschwindigkeitsvorteil beim laden sollte bei kleinen Tools auch zu 
vernachlässigen sein. Und: Es gibt Leute die behaupten steif und fest 
das (zumindest unter Linux) ungestrippte Programme genauso schnell 
geladen werden wie gestrippte. Was wohl einfach damit zusammenhängt das 
die Debuginformationen gar nicht in den Speicher geladen werden, 
sondern lediglich der ausführbare Code.
KDE aufner Sun über NFS wird gestrippt jedoch schneller geladen. Glaube 
ich :)
Mfg
--
Andrey Behrens
> Schneller läuft das Programm nur insofern, als das das binary kleiner
> wird und dadurch schneller geladen werden kann.
»King Leo«, Du möchtest Dich mal über demand paging informieren,
bevor Du anderen Anfängern Märchen erzählst.
Grüße,
	Gunnar
> KDE aufner Sun über NFS wird gestrippt jedoch schneller geladen. Glaube 
> ich :)
Es ist ziemlich unwarscheinlich das es stimmt.
-Andi
> Was ist der Sinn des Programms "strip"?
> Jemand hat mir gesagt, wenn man die Symbole aus einem Programm strippt,
> läuft das Programm schneller. Aber welche Symbole kann man entfernen?
Nein, es lädt schneller und belegt weniger Platz auf der Platte, aber es
läuft i. d. R. nicht schneller.
> Alle oder nur die Debug-Symbole?
Wenn es nicht dynamisch andere Module nachlädt, alle.
> Warum sind die Symbole überhaupt erst drin, wenn man sie wieder
> entfernen kann? Die Manpage verrät über den Sinn & Zweck nur sehr
> wenig.
"info gcc" sagt aber was zu "-g": Debugsymbole einbauen. Unaufgefordert
wirft der gcc auch nicht mehr als eine Version und den für den Linker
nötigen Symbolen ins Programm -- und die kann man beim fertig gelinkten
Programm entfernen.
-- 
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin  dont_click_this_virus.exe
end
Denk doch einmal nach!
NFS -> Netzwerk!!!
Das bedeuted, das das binary rübergeschickt werden muß.
Und wenn nun die Datei dank strip kleiner is, wird das Teil nun mal
schneller geladen.
-- 
Resistance is futile!
> NFS -> Netzwerk!!!
> 
> Das bedeuted, das das binary rübergeschickt werden muß.
Nein. *So* schlimm ist NFS auch nun wieder nicht.
> Und wenn nun die Datei dank strip kleiner is, wird das Teil nun mal
> schneller geladen.
Damit ist diese Schlußfolgerung hinfällig.
Fazit:
(Strippen bringt nichts, außer dass die Binaries kleiner sind. Und das ist 
bei den heutigen HD-Preisen irrelevant.)?
> Nein. *So* schlimm ist NFS auch nun wieder nicht.
Naja, das kommt wohl auch auf die Geschwindigkeit des NFS-Servers und 
der Verbindung zwischen meiner Workstation und dem Server an. :)
Mfg
--
Andrey Behrens
> Denk doch einmal nach! 
> 
> NFS -> Netzwerk!!!
> 
> Das bedeuted, das das binary rübergeschickt werden muß.
> 
> Und wenn nun die Datei dank strip kleiner is, wird das Teil nun mal
> schneller geladen.
Das Programm wird seitenweise (=in 4K oder uU auch 8K Bloecken) geladen 
wenn das Programm auf die entsprechende Seite zugreift. Das Programm
selber greift nie auf die Debugginginformationen oder die Symboltabellen
die nicht zum dynamischen Linken (= die die von Strip gestript werden) 
zu.  NFS uebertraegt nur die benoetigten Seiten. Deswegen macht es keinen
Unterschied.
-Andi
> Fazit: (Strippen bringt nichts, außer dass die Binaries kleiner
> sind. Und das ist bei den heutigen HD-Preisen irrelevant.)?
So in etwa.
Trotzdem gibt es Leute, die grundsätzlich ihre Binaries strippen.
Steht das nicht auch in der Debian Policy drin? 
> > Nein. *So* schlimm ist NFS auch nun wieder nicht.
> 
> Naja, das kommt wohl auch auf die Geschwindigkeit des NFS-Servers und 
> der Verbindung zwischen meiner Workstation und dem Server an. :)
Das hat aber mit Debugging-Informationen nichts mehr zu tun.
> Das Programm wird seitenweise (=in 4K oder uU auch 8K Bloecken)
> geladen wenn das Programm auf die entsprechende Seite zugreift. Das
Naja. Ich schrieb ja "ich glaube".
Selig sind die Glaubenden, den ihrer ist das Himmelsreich. ;-)
Mfg
-- 
Andrey Behrens
Du gehörst gehauen, und zwar mit der neunschwänzigen Ethernet-Peitsche!
man embedded
man backup
Felix
Und bei einigen Programmen sind die Debuginformationen heftig (600 KB => 200
KB durch Strippen). Und ein Programm mit Symboltabelle bringt auch keine
beseren Fehlermeldungen bei normalem Start.
-- 
Frank
> »King Leo«, Du möchtest Dich mal über demand paging informieren,
> bevor Du anderen Anfängern Märchen erzählst.
Apropos, warum sind ELF-Executables eigentlich demand-pageable,
obwohl ihre einzelnen Sektionen (anders als bei a.out) nicht
page-aligned sind?
-- 
Christian "naddy" Weisgerber                          na...@mips.inka.de
> Gunnar Ritter <g...@bigfoot.de> wrote:
> 
> > »King Leo«, Du möchtest Dich mal über demand paging informieren,
> > bevor Du anderen Anfängern Märchen erzählst.
> 
> Apropos, warum sind ELF-Executables eigentlich demand-pageable,
> obwohl ihre einzelnen Sektionen (anders als bei a.out) nicht
> page-aligned sind?
"Ueberstehende" Header oder andere Segmente werden einfach doppelt oder
zusaetzlich gemappt. Der Linker stellt allerdings sicher das die virtuellen
Addressen zum Fileanfang relativ stimmen.
(aus dem TLS spec) 
>>
Although the example's file offsets and virtual addresses are
congruent modulo 4 KB for both text and data, up to four file pages
hold impure text or data (depending on page size and file system block
size).  The first text page contains the ELF header, the program
header table, and other information.
The last text page holds a copy of the beginning of data.  The first
data page has a copy of the end of text.  The last data page may
contain file information not relevant to the running process.
Logically, the system enforces the memory permissions as if each
segment were complete and separate; segments' addresses are adjusted
to ensure each logical page in the address space has a single set of
per- missions.  In the example above, the region of the file holding
the end of text and the beginning of data will be mapped twice: at one
virtual address for text and at a different virtual address for data.
The end of the data segment requires special handling for
uninitialized data, which the system defines to begin with zero
values.  Thus if a file's last data page includes information not in
the logical memory page, the extraneous data must be set to zero, not
the unknown contents of the executable file.  ``Impuri- ties'' in the
other three pages are not logically part of the process image; whether
the system expunges them is unspecified.  The memory image for this
program follows, assuming 4 KB (0x1000) pages.
<<
-Andi
> Trotzdem gibt es Leute, die grundsätzlich ihre Binaries strippen.
> Steht das nicht auch in der Debian Policy drin? 
Ja, in Anbetracht der Tatsache, daß eine ganze Menge Leute sich ihre
Debian-Pakete über Modem ohne Flatrate holen ...
Anselm
-- 
Anselm Lingnau .......................................... ans...@strathspey.org
In looking at a drop of water under a microscope, we find there are twice as
many H's as O's.                            -- Junior high school science essay
> Florian Weimer  <Florian...@RUS.Uni-Stuttgart.DE> schrieb:
>
>> Trotzdem gibt es Leute, die grundsätzlich ihre Binaries strippen.
>> Steht das nicht auch in der Debian Policy drin? 
>
> Ja, in Anbetracht der Tatsache, daß eine ganze Menge Leute sich ihre
> Debian-Pakete über Modem ohne Flatrate holen ...
Na, wenn *das* ein Grund wäre, dann gäbe es doch schon längst Deltas
für alle Pakete.
> Na, wenn *das* ein Grund wäre, dann gäbe es doch schon längst Deltas
> für alle Pakete.
Darüber wird immer mal wieder geredet, aber es hat sich (a) noch
niemand gefunden, der vernünftig erklären konnte, wie das genau
funktionieren sollte (wenn es tatsächlich was bringen soll, ist es ein
bißchen komplizierter, als es sich im ersten Moment anhört),
geschweige denn (b) jemand gefunden, der das tatsächlich
implementiert.
Und bis das schließlich eines Tages mal passiert, gibt es halt
komplette Pakete mit gestrippten Binaries. Der Lauf der Welt ...
Anselm
-- 
Anselm Lingnau .......................................... ans...@strathspey.org
The reasonable man adapts himself to the world: the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man.             -- George Bernard Shaw, *Man and Superman* (1903)
Seit wann halten sich Debug Symbole und Programm Code an Page Grenzen??
-- 
Laut einer repräsentativen EMNID-Umfrage sehen 46% der Linux-Nutzer
"Stabilität" als Vorzug ihrer Plattform; bei den Windows-Anwendern sind 
dies nur 13%.
               (http://www.suse.de/de/news/PressReleases/emnid_studie/11.html)
> Seit wann halten sich Debug Symbole und Programm Code an Page Grenzen??
Programme werden heuer nicht mehr komplett in den Speicher geladen,
bevor sie gestartet werden, sondern es werden nur diejenigen Seiten
geholt, die tatsächlich während des Programmlaufs benötigt werden
(sog. »demand paging«). Wenn der Code geschickt angeordnet ist -- also
keine Sprünge quer durch das gesamte Binary ausführt --, dann ist die
Größe des Binary erst mal relativ egal.
Für Windows gibt es dem Vernehmen nach geschickte Linker, die die
Funktionen im Binary entsprechend sortieren, um einen schnellen
Programmstart zu ermöglichen. Bei Unix hat sich da noch niemand so
richtig die Mühe gemacht, was auch daran liegen mag, daß traditionelle
Unix-Programme klein und spezialisiert sind. Bei großen Programmen à
la Sta^H^H^HOpenOffice ist das natürlich eher ein Problem.
Anselm
-- 
Anselm Lingnau .......................................... ans...@strathspey.org
Don't accept your dog's admiration as conclusive evidence that you are
wonderful.                                                       -- Ann Landers
> King Leo - Martin Oberzalek  <kin...@gmx.at> schrieb:
>> Seit wann halten sich Debug Symbole und Programm Code an Page Grenzen??
Warum, kleiner King-Kong, liest Du nicht einfach den ganzen Thread,
bevor Du Fragen stellst, die schon längst beantwortet wurden?
> Für Windows gibt es dem Vernehmen nach geschickte Linker, die die
> Funktionen im Binary entsprechend sortieren, um einen schnellen
> Programmstart zu ermöglichen. Bei Unix hat sich da noch niemand so
> richtig die Mühe gemacht, [...]
Zumindest UnixWare/Open UNIX kennt »fur«, »function and object code
rearranger«, für verwandte Zwecke.
Grüße,
	Gunnar