[OSy] Problemy s prekladacem

Tom� Martinec fyzmat at gmail.com
Sat Dec 6 03:48:14 CET 2008


Samozrejme mate uplnou pravdu.

V kernelu definujeme:
#define PAGE_SIZE PAGE_TABLE_ENTRIES * PAGE_TABLE_ENTRY_SIZE

Coz vede ke spatnemu vyhodnoceni vyrazu. Nikoho z nas tato moznost nenapadla...
Omlouvam se.

Tomas Martinec

Dne 6. prosinec 2008 1:47 Vlastimil Babka <babka at dsrg.mff.cuni.cz> napsal(a):
> Tom� Martinec wrote:
>>
>> Dobry den,
>>
>> Pri testovani map1 jsme narazili na problem, o kterem se domnivame, ze
>> jde o chybu prekladace. Spociva v tom, ze kod testu
>> pomoci funkce vma_alloc pozada o prideleni bloku virtualni pameti a
>> nas kernel mu ji poskytne na adrese 0xC0000000. Kod testu (jedna se o
>> rutinu action_vma_alloc()) si zaznam o alokovane oblasti uklada do
>> svych internich struktur, predtim vsak virtualni adresu vydeli
>> velikosti stranky:
>>
>>                /*
>>                 * The pointer is OK, convert it to page number, add
>>                 * the area to the area list and check for overlaps.
>>                 */
>>                printk ("Before %x\n", alloc_ptr);
>>
>>                msim_trace_on ();
>>                int alloc_page = (unsigned int) alloc_ptr / PAGE_SIZE;
>>                msim_trace_off ();
>>
>>                printk ("After %x\n", alloc_page);
>>                msim_stop ();
>>
>> Pokud ma tedy adresa pridelena funkci vma_alloc hodnotu 0xC0000000,
>> mel by si kod testu ulozit hodnotu 0xC0000, misto toho je vsak ulozena
>> 0xC00000. To se projevi pri zpetnem vypoctu adresy virtualni oblasti,
>> ktera vyjde 0x00000000. Kod testu se nasledne pokusi na tuto adresu
>> zapsat data, coz vede k vyjimce TLB miss a k zabiti aktualniho vlakna.
>>
>> Pri sledovani toku instrukci jsme zjistili, ze na radku
>>
>> int alloc_page = (unsigned int) alloc_ptr / PAGE_SIZE;
>>
>> nedochazi k bitovemu posunu doprava o dvanact bitu, ale nejprve k
>> bitovemu posunu o deset bitu doprava a nasledne dva bity doleva.
>>
>> Odpovidajici vystup ze simulatoru:
>>                Before C0000000
>>                 0  800094AC    d_trace
>>                 0  800094B0    lw    s0, 0x18(sp)      # 0x18=24, s0:
>> 0x0->0xc0000000
>>                 0  800094B4    srl   s0, s0, 0x0a      # 0xa=10, s0:
>> 0xc0000000->0x300000
>>                 0  800094B8    sll   s0, s0, 0x02      # s0:
>> 0x300000->0xc00000
>>                After C00000
>>
>> Prekladali jsme na platforme win32 s prekladacem verze 4.3.2. Dnes
>> jsme to zkouseli i na unixovem stroji s prekladacem 4.1.1 se stejnym
>> vysledkem.
>>
>> Takze, radi bychom se zeptali, jestli se nekdo z ostatnich take setkal
>> s podobnym problemem a jestli nekoho nenapada nejake jine vysvetleni
>> nez ze chyba prekladace.
>>
>>
>
> Dobry vecer,
>
> chyba prekladace mi prijde jako malo pravdepodobny duvod. Ale v pripade ze
> ano, menili jste nejak CCFLAGS s kalista nebo jsou stejne?
> Jako pravdepodobnejsi pricinu bych videl makro PAGE_SIZE. Jak presne je ve
> Vasem kernelu definovane? Testy ho sice definuji samy, ale pouze pokud neni
> jiz definovane pred nim. Neni to treba nejaky vyraz, ktery jste zapomneli
> ozavorkovat, a priorita operatoru '/' ho zcela zmenila, nebo neco podobneho?
>
> Vlastimil Babka
>
> _______________________________________________
> OSy mailing list
> OSy at dsrg.mff.cuni.cz
> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>


More information about the NSWI004 mailing list