section coderes is full ( section .text )

Willkommen!

Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.

    moin,


    leider stoße ich immer wieder auf das gleiche Problem.
    ok Code kann man ja in verschiedene Sektionen stecken, mache ich auch.


    in der text-Sektion sind doch aber nur Variablen und Konstanten drinn oder ?


    Ok also verwende ich anstatt einer Instanz einer Klasse einen Zeiger:
    //CKlasse klasse
    CKlasse* klasse = new CKlasse;


    so jetzt ist die Linkermeldung weg.
    doch irgendwann muß ja mal


    delete klasse;
    geschrieben werden, zwischen new und delete steht mal Testweise nichts
    und die Linkermeldung der vollen text-Sektion ist wieder da ...



    Wie organisiert Ihr den Eure größeren Programme ?
    Leider bin ich an einem Punkt angekommen, wo ich auch nicht mal ein paar Variablen wegschmeissen kann :(


    Grüße
    RB, mit PRC-Tools

    Hallo,
    leider kann ich nichts nützliches hier beitragen.


    Mich würde nur mal der Hintergrund interessieren.
    Liegt das an der Chunkgröße von 64k?

    Mein PRC ist nun 96K groß (erstellt mit der PODS in C).
    Ab wann und wieso gibts dann diese Probleme?

    • Offizieller Beitrag

    Probleme gibt's, wenn ein Codesegment größer als 32kB wird. Der Grund liegt in der Art und Weise, wie Sprünge gemacht werden. Die sind normalerweise unter PalmOS relativ und dann ist der Offset max. 32 kB. Der Grund für die relativen Sprünge liegt IMHO in darin, das PalmOS Programme nciht an festen Adressen stehen, sondern irgendwo stehen können, wo halt gerade Platz ist im Storage Mem. Da die Dragonball CPU weder eine MMU hat (umwie unter Windows dafür zu Sorgen, das die Anwendung immer im gleichen virtuellen Speicherbereich ausgeführt wird) noch die Resourcen für Reallokation vorhanden und notwendig waren (um wie beim Amiga die Sprünge neu zu berechnen) behalf man sich mit der Nutzung der raltiven Adressierung der m68k CPU. Multisegment-Applikationen gehen über Sprunginseln. Das Chunklimit von 64kB trug nicht dazu bei, das alles einfacher zu machen...


    Gruß
    Henk

    Danke für die Ausführung


    wenn ich mit PODS eine 68K Appl. in C erstelle wo ein relativer Sprung über 32K erfolgen kann wird das dann automatisch eine Multisegment-Applikation?
    Macht das der Linker dann automatisch oder hab ich nur immer Glück gehabt.
    Mein prc ist bis jetzt immer gelaufen, abgesehen von diversen anderen Bugs


    danke mti

    • Offizieller Beitrag

    Ich glaube, das er es automatisch macht, wenn man das entsprechende Projekt auswählt. Aber über die 32kB zu kommen bedarfr schon einer etwas größeren Applikation. Du darfst nicht vergessen, das das executable aus mehr als nur Code besteht, es gibt globale Variablen, Konstanten etc. Im prc sind dann noch alle Grafiksachen mit drin.

    Hallo,
    mal wieder das gleiche Problem.
    Nun dachte ich mir es mal richtig anzugehen. Der Plan eine
    externe ResourcenDatei (appres.prc) welche von der eigentlichen
    app.prc verwendet wird. Es sind ja auch die Formulare welche in
    der .text section sind ...


    Nur wie kann ich das umsetzten. FrmGotoForm will eine ResID des
    Forumlares. Mit GetResource() bekomme ich aber nur ein MemHandle
    zurück. Ich hatte einige #define "Zeichenfolge" im Code. Dachte
    mir wenn ich das alles in die Resourcen übernehme und mit Get1Resource
    mir hole spare ich was an der .text Section. Is aber offensichtlich nicht :-).


    Ich habe ein Bsp. für die PRC-Tool mit denn ich arbeite. Es demonstriert
    die Verwendung einer Shared-Lib ( *.prc ) mit Funktionsaufrufen.


    Ich bin mir nicht sicher ob wenn ich in die shared Lib meien Forms packe
    und die sharedlib.h wie im Bsp. nur einbinde ob ich dann die Formulare
    aufrufen könnte. Rein C-Technisch sollte es funzen.


    Bin mir aber nicht sicher ob dann die .text Section der beiden *.prcs
    nicht zusammen nur 32K sein dürfen oder ob tatsächlich die 32K für jede *.prc gilt.


    Grüße
    RB

    Goil !
    Passt, war nur zu ungedultig. Hatte schon mehrere
    #define nach rcp gebracht, was aber noch nicht reichte
    und sich Zweifel einstellten.
    Grüße
    RB


    EDIT:
    wobei irgend was stimmt hier auch nicht.
    an beliegiger stelle steht ein
    #define LTEXT "LAAAANGERText"


    LTEXT wird jetzt in einer Funktion welche in einem
    Segment "util" steckt verwendet.


    Dann liefert m68k-palmos-objdump --section-headers util.o
    für .text den selben Wert als wenn KTEXT
    #define KTEXT "kurzerText"
    verwendet wird. Hingegen wird für seg util ein kleinerer Wert angegeben


    Eigentlich soweit logisch, nur die #defines in die rcp als Resourcen zu übernehmen bringt so nichts. Weiß auch nicht was ich vorher gemacht habe. :evil: als ich dachte es funktioniere ... ;(


    Grüße
    RB, auf der suche nach .text Space ... 8)