"컴파일 된 바이너리" 에서 "함수 호출 부분이 사라졌다" 고 썼다면 아마도 질문글을 쓰는 도중에 본인이 스스로 답을 찾았을 것 같습니다.
그 정도 최적화는 gcc 2.x 에도 있었습니다.
점점 더 빡세 진 것은 함수를 inline 시켜버리는 쪽이고... 언뜻 보면 디버깅 정보에 심볼들이 보여서 inline 안되고 남아있는 것 처럼 보여도, call 대신 jump 를 쓰면서 스택 프레임을 바꾸지 않는 코드를 만들어내는 바람에 나중에 back trace 때 함수 호출 경로에 듬성등성 이빨이 빠져서 상당한 혼란을 겪죠.
함수가 사라진다는 말이 무슨 뜻인가요 ?https:/
함수가 사라진다는 말이 무슨 뜻인가요 ?
https://elixir.bootlin.com/linux/latest/A/ident/memcpy
답을 골라야한다면, 휴먼 에러라는 쪽에 50원 걸겠습니다.
이런 상황입니다.
static ssize_t test_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos) { char arr[8] = { [0 ... 7] = 0 }; char *ptr; ptr = (char *)kmalloc(count, GFP_KERNEL); copy_from_user(ptr, buf, count); memcpy(arr, ptr, 8); // wtf return 0; }file_operations에 write로 등록된 함수입니다.
위 코드에서 memcpy 부분이 작동을 안해서 어셈으로 확인해 봤더니
이와 같이 memset이 아예 사라져 버렸습니다. 이거 설마 undefined behavior 일까요? undefined behavior가 아예 함수 호출을 스킾하는 경우도 있나요..?
...
arr는 로컬 변수인데 함수가 끝나면 아무 역할도 못하고 사라지겠죠. 따라서 컴파일러가 보기에 memcpy가 있으나 마나 프로그램의 진행에 아무런 영향이 없습니다. 그러므로 최적화 과정에서 날려 버릴 수 있습니다.
테스트 해보니 gcc의 최적화 때문이 맞았네요.
테스트 해보니 gcc의 최적화 때문이 맞았네요. gcc 10으로 업데이트 한 뒤에 뭔가 최적화가 더 빡세진? 느낌입니다.. 답변 감사합니다.
"커널에 적재" 하니 "함수가 사라졌다"고 쓰는대신,
"커널에 적재" 하니 "함수가 사라졌다"고 쓰는대신,
"컴파일 된 바이너리" 에서 "함수 호출 부분이 사라졌다" 고 썼다면 아마도 질문글을 쓰는 도중에 본인이 스스로 답을 찾았을 것 같습니다.
그 정도 최적화는 gcc 2.x 에도 있었습니다.
점점 더 빡세 진 것은 함수를 inline 시켜버리는 쪽이고... 언뜻 보면 디버깅 정보에 심볼들이 보여서 inline 안되고 남아있는 것 처럼 보여도, call 대신 jump 를 쓰면서 스택 프레임을 바꾸지 않는 코드를 만들어내는 바람에 나중에 back trace 때 함수 호출 경로에 듬성등성 이빨이 빠져서 상당한 혼란을 겪죠.
정정
memset -> memcpy
댓글 달기