Re: about "size" from binutils
Hallo Bjoern,
Bjoern Schliessmann <usenet-mail-0306.20.chr0n0ss@spamgourmet.com> wrote:
> Jörg Sommer wrote:
>> Malloc, genauer brk,
>
> Nein.
Malloc() ist kein System‐Call. Aus dem Grund kannst Du malloc() auch
nicht mit strace sehen.
http://en.wikipedia.org/wiki/Malloc#The_glibc_allocator
>> verändert doch die Größe des data Segments.
>
> Habe mal ein bisschen zu brk gelesen. Damit kann man anscheinend die
> Größe des data-Segments im Speicher zur Laufzeit verändern,
> allerdings ist das ein ziemlich unkomfortabler Eingriff (und AFAIK
> keine C-Standardfunktion).
Wenn Du mit C‐Standardfunktion meinst, dass sie im ISO‐Standard
definiert ist, dann natürlich nicht. Alle systemspezifischen Funktionen
wie setrlimits() oder sigaction() sind nicht im ISO‐Standard.
>> Welche Funktion erfüllt das bss Segment?
>
> Ein uninitialisiertes int-Array wie das hier:
>
> int honk[1000000];
>
> würde das Executable z. B. fast ein MB größer machen, weil zur
> Compilezeit der komplette Speicherbereich im data-Segment
> reserviert würde. Das Array enthält aber keinerlei Nutzdaten,
> sondern wird erst später im Programmablauf "gefüllt". Deshalb ist
> es sinnlos, es in kompletter Länge im Executable unterzubringen.
>
> Deshalb gibt es das bss-Segment. Dort liegen uninitialisierte
> Variablen. Es braucht keinen Platz im Executable, weil dort drin
> nur steht, wie groß es sein muss. Beim Laden des Executables
> reserviert das Betriebssystem einen Speicherbereich der angegebenen
> Größe und packt ihn mit zum Prozess dazu.
Das erklärt aber nicht, warum nicht einfach beim Programmstart ein
dynamischer Speicher angefordert wird. Man könnte sich doch den ganzen
Verwaltungsaufwand für ein weiteres Segment sparen und stattdessen
erzeugt der Compiler für den Start des Programms ein Stück Code, das vom
System Speicher anfordert.
> (Das führt für gewöhnlich dazu, dass uninitialisierte Variablen
> Zufallswerte erhalten, weil das Betriebssystem entgegen der
> Empfehlung das bss-Segment vor dem Start des Programms nicht
> nullt.)
Das ist abgesehen von sicherheitstechnischen Belangen kein Problem.
Entweder erzeugt der Compiler einen memset()‐Aufruf für den Start des
Programms oder man beruft sich darauf, dass Lesen vor Schreiben zu
undefiniertem Verhalten führt.
Schöne Grüße, Jörg.
--
[dpkg] We are the apt. Resistance is futile. You will be packaged.
Reply to: