-         

Ergebnis 1 bis 8 von 8

Thema: relocation truncated to fit

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672

    relocation truncated to fit

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Hallo,

    ich habe ein seltsames Problem und kann es mir nicht erklären. Folgender Code:

    Code:
    #define MSG_off   9
    //...
    void LCD_Text_EEPROM (U16 Offset)
    {
     U8 Zeichen = eeprom_read_byte ((uint8_t *)(uint16_t)Offset);
     while (Zeichen != 0)
     {
      LCD_Zeichen (Zeichen);
      Offset++;
      Zeichen = eeprom_read_byte ((uint8_t *)(uint16_t)Offset);
     }
    }
    //...
    void LCDMsg (U8 Msg)
    {
     U16 Addr = Msg<<4;
     LCD_Text_EEPROM (Addr);
    }
    //...
    int main (void)
    //...
    switch (GSM_Status)
    {
     case 0:  { LCDMsg (MSG_off);
    //...
    Wenn ich das compiliere erhalte ich als Fehlermeldung: P:\AVR\test.c:1186: relocation truncated to fit: R_AVR_7_PCREL against `no symbol'
    Zeile 1186 ist dabei die switch-Zeile.

    Bei Google habe ich herausgefunden, dass es was mit der Reihenfolge der eingebundenen Bibliotheken zu tun haben könnte. Die Funktionen LCD_Text_EEPROM und LCD_Zeichen sind tatsächlich in einer externen Bib. Aber egal an welche Reihenfolge ich diese Bib einbinde, der Fehler bleibt. Seltsam ist dass das Programm fehlerfrei compiliert wird und läuft, wenn ich die Zeile LCDMsg (MSG_off); auskommentiere. Seltsamerweise sind davor und danach aber auch aufrufe von LCDMsg. Es scheint nur ein Problem an dieser einen Stelle zu geben. Wie komme ich dem Problem auf die Schliche?

    Viele Grüße
    Andreas

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Du, mit den geschweiften Klammern im "int main()" komm' ich nicht klar ?
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672
    Hallo PicNick,

    die int main besteht mittlerweilse aus fast 500 Zeilen. Ich habe zur Übersichtlichkeit deshalb nur den relevanten Teil gezeigt. Hier ist etwas mehr Code:

    Code:
      LCD_Cursor (1, 4);
      LCDMsg (MSG_GSM);
      switch (GSM_Status)
      {
       case 0:  { LCDMsg (MSG_off); break;}
       case 1:  { LCDMsg (MSG_boot); break;}
       case 2:  {  LCDMsg (MSG_config); break;}
    //...noch ein paar mehr...
    }
    Es funktioniert alles, bis auf die Zeile bei case 0. Ich kann auch den Wert der Konstanten LCD_off von 9 auf einen anderen Wert ändern, es hilft alles nichts.

    Wenn ich in die Zeile statt dessen folgendes schreibe:

    Code:
    LCD_Text_EEPROM (144);
    funktioniert alles. Ein seltsames Problem wie ich finde. Zwei Zeilen vorher funktioniert der Aufruf, zwei Zeilen nachher, nur genau an dieser Stelle erhalte ich die komische Fehlermeldung. Ich habe den Teil mit dem switch bereits in eine Funktion gepackt und auch diese etwas im Programm hin und hergeschoben. Das hat aber leider auch nicht geholfen.

    Viele Grüße
    Andreas

  4. #4
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Tscha. Bin ich für Einkreisen.
    1) lass beim "Case" die geschweiften weg, also einfach
    Code:
    case 0: LCDMsg(MSG_off);  break;
    2) den "call" aus dem "switch" testweise rausnehmen (davor)
    Code:
      LCD_Cursor (1, 4);
      LCDMsg (MSG_GSM);
      LCDMsg(MSG_off);              
      switch (GSM_Status)
      {
          etc
    nur um festzustellen, obÄs um den function-call geht, oder ob es was mit dem "Switch-case" zu tun hat.

    Wie sind denn U16 und U8 deklariert ? mit oder ohne * ?
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672
    Ich habe es jetzt gerade noch mal probiert und jetzt läuft es. Das Programm ist schon ein paar Tage fertig und funktioniert, ich bin zur Zeit nur noch am Feinschliff und Optimieren. Es wurden inzwischen eine handvoll Codezeilen an verschiedenen Stellen geändert und nun taucht der Fehler nicht mehr auf. Seltsam!

    Vorschlag 2 hatte ich bereits probiert, das hat nicht zum Erfolg geführt.

    Welche U16 bzw. U8 meintest du genau?

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Das Problem ist ein zu großer Offset in einem relativen Spring, vermutlich wegen inline assembler.

    Wie sieht das mit -save-temps erzeugte Präcompilat (i-File) und das s-File aus?
    Disclaimer: none. Sue me.

  7. #7
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672
    Guten Morgen SprinterSB,

    danke für deine Erklärung. Ich nutze kein inline assembler. Woran hätte es dann noch liegen können?

    Wie lange dürfen denn die Sprünge sein, bzw. entscheidet nicht der Compiler bzw. Linker, ob er einen relativen oder absoluten Sprung machen muss?

    Mein Controller ist fast voll (>99%). Ich nutze eine eigene Bibliothek (LCD). Die Funktionen daraus werden überall im Programm verwendet. Da der Fehler auch beim Aufruf einer Funktion aus dieser Bibliothek aufgetreten ist, und du sagst dass ein Sprung zu lange ist vermute ich das die Bibliothek nicht "in der Mitte" des Programms gelinkt werden konnte und somit vielleicht der Fehler aufgetreten ist.

    Leider kann ich den Fehler nicht mehr reproduzieren. Ich hätte ein Backup vom "defekten" Stand machen sollen für weitere Analysen.
    Aber die Hauptsache ist ja, dass es jetzt funktioniert.

    Viele Grüße
    Andreas

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Dazu kann man nur eine Aussage machen, wenn man das nachvollziehen kann. Ansonsten ist's Rumgerate.

    Evtl. war auch der µC voll und ein Spring ging zu dem Stück > 100%. Oder du verwendest Optionen wie -mshort-calls ohne zu wissen, was du tust
    Disclaimer: none. Sue me.

Ähnliche Themen

  1. gcc/as - problem: relocation truncated bei .extern
    Von RedEagle im Forum Assembler-Programmierung
    Antworten: 0
    Letzter Beitrag: 01.12.2010, 09:15
  2. Antworten: 1
    Letzter Beitrag: 24.05.2007, 21:44
  3. Antworten: 9
    Letzter Beitrag: 23.07.2005, 11:30

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •