IMetaDataImport::GetMethodProps가 반환하는 IL 코드 주소(RVA) 문제
IMetaDataImport::GetMethodProps는 IL 코드 주소에 대해 RVA로 반환해 줍니다.
IMetaDataImport::GetMethodProps Method
; https://learn.microsoft.com/ko-kr/dotnet/framework/unmanaged-api/metadata/imetadataimport-getmethodprops-method
가령, 다음과 같이 코드를 사용하면,
DWORD dwImplFlags = 0;
ULONG ulCodeRVA = 0;
hr = m_pMetaDataImport->GetMethodProps(...[생략]..., &ulCodeRVA, &dwImplFlags);
// hr == 0x00131106 (Data value was truncated)
해당 메서드의 IL 바이트 위치가 ulCodeRVA에 어셈블리의 로딩 주소에 대한 상대값으로 나오게 됩니다. 그런데, 재미있는 것은 저 규칙이 ASP.NET Core 2.1 웹 응용 프로그램을 docker container 환경에서 실행했을 때 예외가 발생한다는 점입니다.
실제로 제가 테스트한 환경에서 다음과 같은 구성으로 값이 설정되었는데,
어셈블리 로드 주소: bce29000
ulCodeRVA: 2050
그렇다면 코드 주소가 bce2b050으로 계산이 되지만, IL 코드의 주소를 반환해주는 또 다른 메서드인 GetILFunctionBody를 사용해 보면,
ICorProfilerInfo::GetILFunctionBody Method
; https://learn.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의 버그라고 단정 짓기도 모호하군요. ^^
이 외에도, GetMethodProps는 윈도우와 리눅스 환경에서 다른 동작을 하나 보이는 것이 있습니다. 일례로, 다음과 같이 코딩을 한 경우,
ULONG count = 0;
uchar16 wszFunctionName[512];
hr = m_pMetaDataImport->GetMethodProps(..., wszFunctionName, 512, &count, ...);
이때 만약 메서드의 이름이 512자를 넘는다면 hr 반환값이 CLDB_S_TRUNCATION(0x00131106 - "Data value was truncated")이 됩니다. 여기서 문제는, 윈도우의 경우 그래도 전달된 wszFunctionName 버퍼에는 512개까지의 문자가 담겨서 넘어오는 반면, 리눅스에서는 아예 빈 문자열로 나온다는 점입니다. 따라서, 저 코드를 유연하게 하려면 애당초 고정 버퍼보다는 동적 할당 버퍼를 쓰는 것이 더 낫습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]