logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Problem z overlaps section .text w AVR

demoh 12 Wrz 2008 20:22 1229 5
REKLAMA
  • #1 5529550
    demoh
    Poziom 19  
    Mam taki kod linkera:

    MEMORY
    {
    	CODE (xr) : ORIGIN = 0x0000, LENGTH = 128K
    	DATA (rw) : ORIGIN = 0x0100, LENGTH = 4K
    }
    
    SECTIONS
    {
    	.text 0x0000 :
    	{
    		*(.text)
    	}
    	. = ALIGN(2);
    
    	.rodata :
    	{
    		*(.rodata) 
    	}
    	. = ALIGN(2);
    
    	.data :
    	{
    		*(.data)
    	}
    	. = ALIGN(2);
    
    	.bss :
    	{
    		*(.bss)
    	}
    	. = ALIGN(2);
    }



    I dopuki kod zajmowal mniej niz 256 bajtow to wszystko sie linkowalo. Po przekroczeniu 256 bajtow kodu wykonywalnego pojawia sie blad linkowania:

    avr-ld: section .bss [0000000000000100 -> 0000000000000105] overlaps section .text [0000000000000000 -> 00000000000001b5]
    


    Czyli krzyczy, ze kod wykonywalny wchodzi na dane. Wiemy ze kod trzymany jest w pamieci FLASH a reszta w SRAM, ale jak to powiedziec linkierowi?

    Troche dziwne :/ Chyba ten linkier z GCC jest zbyt mocno nastawiony na maszyny z pamiecia przechowujaca kod i dane programu.

    Z gory dziekuje za pomoc :)
  • REKLAMA
  • Pomocny post
    #2 5529997
    skritland
    Poziom 13  
    demoh napisał:
    Mam taki kod linkera:

    MEMORY
    {
    	CODE (xr) : ORIGIN = 0x0000, LENGTH = 128K
    	DATA (rw) : ORIGIN = 0x0100, LENGTH = 4K
    }
    
    



    I dopuki kod zajmowal mniej niz 256 bajtow to wszystko sie linkowalo. Po przekroczeniu 256 bajtow kodu wykonywalnego pojawia sie blad linkowania:

    avr-ld: section .bss [0000000000000100 -> 0000000000000105] overlaps section .text [0000000000000000 -> 00000000000001b5]
    


    Czyli krzyczy, ze kod wykonywalny wchodzi na dane. Wiemy ze kod trzymany jest w pamieci FLASH a reszta w SRAM, ale jak to powiedziec linkierowi?

    Troche dziwne :/ Chyba ten linkier z GCC jest zbyt mocno nastawiony na maszyny z pamiecia przechowujaca kod i dane programu.

    Z gory dziekuje za pomoc :)


    A że tak się spytam to skąd i po co taki plik? On przecież generowany jest automatycznie.

    A poza tym to wydaje mi się błędem to przesunięcie 0x0100. Przecież wg linkera gcc to przesunięcie to: 0x00800000 (należy jeszcze uwzględnić rejestry więc dla np. atmega8 to 0x00800060).

    Błąd również wygląda logicznie, bo jak sekcja kodu zaczyna się od adresu 0x0000 i ma u Ciebie 128kB, a dane zaczynają się od adresu 0x0100 (czyli 256B dalej) to muszą na siebie zachodzić :D.
  • REKLAMA
  • #3 5530724
    demoh
    Poziom 19  
    Dla mnie nie logiczne bo FLASH i SRAM sa oddzielnen, nie jak na PC ;)


    Ja wpisalem poprostu z noty katalogowej te adresy. Nie wiedzialem ze GCC troche inaczej to widzi.


    A plik skryptu linkera robie by sie troche go poduczyc :)
  • REKLAMA
  • #4 5532674
    skritland
    Poziom 13  
    demoh napisał:
    Dla mnie nie logiczne bo FLASH i SRAM sa oddzielnen, nie jak na PC ;)


    Ja wpisalem poprostu z noty katalogowej te adresy. Nie wiedzialem ze GCC troche inaczej to widzi.


    A plik skryptu linkera robie by sie troche go poduczyc :)


    Tutaj masz link do dokumentacji avr-libc i w tym linku jest nieco o tym przesunięciu: Link

    Po prostu gcc było tworzone z myślą głównie o PC i twórcy uznali, że taki sposób wskazania, gdzie zaczyna się pamięć danych będzie dobry ;)
  • REKLAMA
  • #5 5535260
    demoh
    Poziom 19  
    Dzieki za linka :)

    Troche zakrecone to jest ale da sie przyzwyczaic :) Teraz program sie kompiluje bez problemu :)
  • #6 5535544
    zumek
    Poziom 39  
    demoh napisał:
    Dzieki za linka :)

    Gdyby autor zaczął - jak przystało - od przeczytania dokumentacji , to nie było by tematu.

    Zamykam.
REKLAMA