본문으로 건너뛰기
피드

Win32 윈도우 프로시저에 다섯 번째 인자를 JIT으로 끼워넣기

backend 약 3분
vote
0
댓글
북마크

Win32 WNDPROC에 컨텍스트 포인터를 전달하는 방법이 마땅치 않은 문제를, JIT 컴파일된 트램폴린으로 다섯 번째 인자를 추가해 해결하는 기법을 소개.

  • 1

    x64 호출 규약을 이용해 트램폴린이 스택 프레임을 만들고 다섯 번째 인자를 추가

  • 2

    로더에게 쓰기+실행 가능 메모리를 요청하여 small code model 유지

  • 3

    Control Flow Guard가 활성화된 상태에서도 동작

  • 4

    실용적 용도는 약한 커스텀 얼로케이터 인터페이스 우회

  • Win32 윈도우 프로시저(WNDPROC)에는 컨텍스트 포인터를 전달할 방법이 없음. 네 개의 파라미터가 전부 Win32가 결정하기 때문. 그래서 보통 글로벌 변수를 쓰거나(지저분함), GWLP_USERDATA에 포인터를 붙이는 방식을 쓰는데(셋업이 번거로움), 이 글에서는 JIT 컴파일된 트램폴린으로 다섯 번째 인자를 추가하는 방법을 소개함

  • 핵심 아이디어: x64 호출 규약에서 처음 네 인자는 레지스터로, 나머지는 스택으로 전달됨. 트램폴린이 새로운 스택 프레임을 만들고 다섯 번째 인자(컨텍스트 포인터)를 스택에 올린 뒤, 원래 네 파라미터는 건드리지 않고 확장된 Wndproc5를 호출하는 구조임

실행 가능한 메모리 할당의 진화

  • 예전에는 VirtualAlloc(또는 mmap)으로 실행 가능 메모리를 할당했는데, 이러면 코드와 데이터에서 2GB 이상 떨어질 수 있어서 상대 주소 지정이 안 됨. 이번에는 로더에게 쓰기+실행 가능한 메모리 블록을 요청하는 방식을 씀

  • GNU 스타일 어셈블리로 .exebuf라는 새 섹션을 정의해서 2MB의 쓰기·실행 가능 메모리를 런타임에 할당함. .bss처럼 동작하되 실행 가능하다는 점만 다름. 이 메모리가 로드된 이미지의 일부이므로 코드·데이터와 가까이 있어서 small code model을 가정할 수 있음

트램폴린 구현

  • make_wndproc 함수가 Wndproc5와 컨텍스트 포인터를 받아서 일반 WNDPROC을 반환함. 어셈블리가 하는 일은 의외로 간단: 새 스택 프레임 할당 → callee shadow space 확보 → 다섯 번째 인자 저장 → 원래 파라미터 그대로 두고 call. 패치해야 할 곳은 컨텍스트 포인터와 32비트 상대 주소 두 군데뿐

  • 컨텍스트 포인터는 나중에 업데이트도 가능하고, 서로 다른 컨텍스트로 여러 프로시저를 만들 수도 있음. Control Flow Guard가 활성화된 상태에서도 동작한다는 게 좀 놀라웠다고 함

  • 저자도 인정하듯이 GWLP_USERDATA보다 작업량이 많고, 실제 프로그램에서 윈도우 프로시저 수는 보통 하나뿐이라 최적의 예시는 아님. 진짜 실용적인 용도는 약한 커스텀 얼로케이터 인터페이스를 우회하는 것 — 런타임에 특정 할당 영역에 바인딩된 할당 함수를 만들 수 있음

C에서 클로저를 만드는 로우레벨 테크닉의 진화. 실무보다는 시스템 프로그래밍의 깊은 이해를 보여주는 글.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.