Newlib -> syscalls - dynamische Speicherverwaltung

[Stefan (Gast)]

Hallo,

ich bin gerade dabei auf einem CortexM4 (STM-Discoveryboard) eine C lib 
zu portieren, die ursprünglich für PC geschrieben wurde.

Ich benutzte die newlib/nanolib + floatingpoint printf und scanf 
Unterstützung.

Da diese lib mit Dateien umgeht, habe ich in die syscalls einen eigenen 
kleinen Dateihandler geschrieben. Das funktioniert auch soweit ganz gut, 
da es sich nur um eine Config-Datei dreht, die dort mit fopen, fread, 
etc. eingelesen wird.

Weiterhin benutzt die lib intensiv dynamischen Speicher mit calloc, 
malloc, free. Irgendwie bekomme ich hier aber Probleme, da es bei einem 
calloc irgendwann im Hardfault landet. Jedoch wird davor einiges an 
calloc ohne Probleme aufgerufen. Ich habe in der syscalls _sbrk schon 
einiges durchprobiert und debuggt. Der heap auch noch reichen. Den hatte 
ich zum Test auch erhöht, es bricht dennoch an der selben Stelle ab 
(Hardfault).

Da meine Beschreibung jetzt nicht zu eindeutig ist, habe ich nur ein 
paar Allgemeine Fragen:

1. Hat jemand einen guten Link wo die syscalls gut anhand des Cortex 
erläutert werden? Die Newlib Doku finde ich nicht gerade ausführlich.
z.B. Obwohl das fread nur 10 Zeichen aus der Datei lesen will, bekomme 
ich ins syscall _read 1024 Zeichen zum auslesen vorgesetzt. Wird da 
irgendwo intern was gebuffert? Also, wo könnte man so was nachlesen?

2. Wie soll das mit dem dynamischen Speicher auf dem CortexM überhaupt 
funktionieren? Mit der minimalen syscalls Implementierung erhalte ich 
bisher kein free (negatives inc) in die _sbrk...
Auch muss doch jeder malloc anschließend sein free ausführen, bevor ein 
weiteres malloc ausgeführt wird, sonst bekommt die einfach + 100 byte - 
100 byte Heapberechnung totale Probleme?! Oder nicht?


Es hat keinen wirtschaftlichen Charakter... ich wills einfach nur für 
mich lernen und habe bisher keine gute Doku gefunden.

Danke

Stefan

[Stefan (Gast)]

hmmm... habs irgendwie hin bekommen...

Habe immer noch das "Problem", dass bei:
caddr_t _sbrk(int incr)

ich bisher kein negatives incr verzeichnen konnte...
Evtl. verwaltet die newlib den nun fragmentierten heap intern selbst 
oder es geht noch etwas grundlegendes schief....

Aktuell läuft alles wie ich es mir vorstelle... es ist aber mehr durch 
probieren als durch Wissen entstanden :-/

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Ich nutze auch die newlibnano. AllerDings habe ich hierzu kein 
Hintergrundwissen. Bei mir erledigt das die ide: visualgdb. Vllt kann 
man dir dort weiterhelfen. Man kann dort zwischen verschiedenen libs 
wählen.

[S. R. (svenska)]

Die Newlib nutzt _sbrk nur, um Speicher zu alloziieren; die eigentliche 
Verwaltung davon findet an anderer Stelle in der Newlib statt. Ich 
wüsste spontan auch nicht, warum der Heap überhaupt verkleinert werden 
sollte - gibt ja nur eine Anwendung.

Streams sind in C normalerweise gepuffert, was die Newlib auch 
implementiert. Beispielsweise wird stdout nur bei Zeilenumbrüchen (oder 
vollen Puffern) geflusht. Dein _read() sollte also nur die vorhandenen 
Daten zurückgeben, und beim nächsten Aufruf dann null (= EOF).

Das alles ist unabhängig vom ARM Cortex und gilt so auf beliebigen 
Architekturen. Im Zweifelsfall musst du in den Code für die Newlib oder 
die entsprechenden Standards gucken.

[Stefan (Gast)]

@S. R.

Erstmal danke für die Info.

Okay, wenn mir die Newlib (nano) das alles schon abnimmt, bin ich nicht 
böse.

Dann werde ich mir jetzt keine tieferen Gedanken darüber machen. Es 
scheint ja soweit zu laufen...

VG

Stefan

[Markus F. (mfro)]

Das traditionalle sbrk() läßt keinen negativen Increment zu.

Bei den Ur-Unixen konnten Prozessimages nur größer werden, nicht 
kleiner.
Das war auch gar nicht notwendig, wenn ein Prozeß mal "zuviel" Speicher 
allokiert hat, der später nicht mehr gebraucht wurde, wurde der halt 
ausgelagert und landete ungenutzt im Swap.

Bei einer Microcontroller-Anwendung ist das natürlich schwierig, wird 
aber auch gar nicht gebraucht - schließlich sind keine anderen Prozesse 
da, die sich um den Speicher streiten könnten.