struct page_load_data *page = NULL;을 하면 포인터 변수 page는 NULL을 가리키고 있으므로 page->file = file;과 같은 접근은 NULL 포인터를 역참조하기 때문에 오류가 발생합니다.: chatgpt 3.5
두 구문은 동일한 동작을 수행합니다.
나도 그렇게 생각해.
hash_find, hash_insert가 서로 상호적으로 움직이지 않음. 즉 insert 해줬는데도 find 하지 못함. suppliment table에 있는 hash의 주소값을 찍으니 insert 할때랑 find 할때 hash의 주소가 달라 그냥 그 spt를 아예 hash로 바꿔주었지만 현상 동일.
이제보니 insert시 va가 0으로 나오길래 보니까 setup stack의 경우 stack임을 표시해주기 위해 상태를 MARKER_0도 쓰기때문에 들어오는 type의 값이 달라서 uninitnew를 안 타서 그런 거였음.
겸사겸사 switch 문으로 바꿔주며 VM_TYPE 매크로 사용.
setup stack이 claim page 까지 하고 나면 success를 true로 반환해주는걸 안 해서 추가.
그 뒤 페이지 폴트가 뜨길래 보니 페이지 단위로 할당은 처음에 되는데, 내가 만약 페이지 중간쯤에 할당은 되었으나 주소는 안 든 부분을 참조하면서 생기는 페이지 폴트를 해결하기 위해 spt find 당시에는 페이지 정렬을 해줘야하기때문에 pg_round_down으로 va를 바꿔서 써야함.
lazy load segment를 하는데, 페이지 폴트. ofs 자체가 제대로 넘어오지 않고 있었음. 그래서 page load data를 담은 구조체를 malloc 해주어야만 손상되지 않고 넘어옴.
이때부터 lazy load까지 했을때 테스트 케이스 패스 횟수만큼 나옴.
그 뒤로 stack growth 하는줄 알았는데 착각함.
stack growth에서 rsp를 Intr_frame으로 넘어오기 위해 cur_rsp라는 항목을 스레드 구조체에 추가하여 do_iret 직전에 rsp를 저장, 1MB 내의 유저 스택 범위내 주소면 stack_growth 함수를 호출하여 필요 데이터만큼 page를 allocate, claim.
pg - stack growth 테스트 케이스를 분석해보니 임의의 값을 4096 꽉꽉 채워 암호화해, 체크섬으로 실제 그 값의 무결성을 체크하는 것인듯. (임의의 값을 랜덤하게 만들어 데이터가 잘 보존되었는지 확인하는거같음.)
1MB내 유저 스택 범위를 정의하기 위해 stack bottom, stack top을 상수로 정의하였음. 그러나 이후 범위인걸 확인하고 나중에 하기 위해 주석처리함.
spt copy, kill, uninit destroy, anon destroy를 다 써봄. 일단 뭐가 죽진 않아도 되는 건 없음. copy에서 바로 복사해야하는 페이지의 정보에 따라 uninit 하고 그에 따라 claim한 뒤 spt에 삽입함.
나중에 보니 file type에 따라 claim 여부를 나누고, 애초에 uninit 자체도 vm alloc page ...로 하고, 데이터 내용 복사를 위해 kva를 memcpy하더라...
kill은 hash_destroy를 쓰나했더니 죽고 그냥 깃북대로 hash table 순회하면서 destroy 선언해주면 됨.
uninit destroy, anon destroy는 free 해줄만한게 내가 넣은 aux의 pag_load_data malloc 해준것 정도라 free 해줬는데 그렇게 하는게 아닐지도.
많은 일이 있었다...
치열한 디버깅이었다...
오후 2시 퀴즈.
벨라디의 역설, 클럭 알고리즘 확인했음.
팀 진행표 갱신함.
어제 공부한 것 정리 및 찾아봄.
copy 부분을 수정할 예정.
2시 퀴즈.
copy, kill, destroy 뽀개기.
fork 가 되도록 완료하기...
그랬으면...좋겠다.
오늘 fork 하고
수 stack growth
목금토 mmap..
일월화... swapinout..
뭐 대강 정말 2주 걸리는듯..