IMetaDataImport::GetMethodProps가 반환하는 IL 코드 주소(RVA) 문제
IMetaDataImport::GetMethodProps는 IL 코드 주소에 대해 RVA로 반환해 줍니다.
IMetaDataImport::GetMethodProps Method
; https://docs.microsoft.com/ko-kr/dotnet/framework/unmanaged-api/metadata/imetadataimport-getmethodprops-method
가령, 다음과 같이 코드를 사용하면,
DWORD dwImplFlags = 0;
ULONG ulCodeRVA = 0;
hr = m_pMetaDataImport->GetMethodProps(...[생략]..., &ulCodeRVA, &dwImplFlags);
해당 메서드의 IL 바이트 위치가 ulCodeRVA에 어셈블리의 로딩 주소에 대한 상대값으로 나오게 됩니다. 그런데, 재미있는 것은 저 규칙이 ASP.NET Core 2.1 웹 응용 프로그램을 docker container 환경에서 실행했을 때 예외가 발생한다는 점입니다.
실제로 제가 테스트한 환경에서 다음과 같은 구성으로 값이 설정되었는데,
어셈블리 로드 주소: bce29000
ulCodeRVA: 2050
그렇다면 코드 주소가 bce2b050으로 계산이 되지만, IL 코드의 주소를 반환해주는 또 다른 메서드인 GetILFunctionBody를 사용해 보면,
ICorProfilerInfo::GetILFunctionBody Method
; https://docs.microsoft.com/ko-kr/dotnet/framework/unmanaged-api/profiling/icorprofilerinfo-getilfunctionbody-method
pCorProfilerInfo->GetILFunctionBody(...[생략]..., &codeAddress, &codeSize);
그 상황에서 codeAddress == bce29250 값이 출력되었습니다. 0x1e00만큼의 차이가 나는 것인데 재미있는 것은 ulCodeRVA 값이 0x2050이 아닌 0x250이 반환되었으면 정확했을 상황입니다.
어쨌든, 위의 사례를 계기로 모든 코드를 RVA 값을 이용하지 않고 GetILFunctionBody를 한번 더 호출하는 것으로 변경했는데... 어쩌면 저 차이가 제가 모르는 리눅스의 ELF 포맷의 런타임 시 추가적인 오프셋 값으로 인한 것일 수도 있으므로 딱히 .NET Core의 버그라고 단정 짓기도 모호하군요. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]