Microsoft MVP성태의 닷넷 이야기
닷넷: 2262. C# - Exception Filter 조건(when)을 갖는 catch 절의 IL 구조 [링크 복사], [링크+제목 복사],
조회: 9929
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

(시리즈 글이 2개 있습니다.)
.NET Framework: 607. C# try/catch/finally의 IL 코드 표현
; https://www.sysnet.pe.kr/2/0/11053

닷넷: 2262. C# - Exception Filter 조건(when)을 갖는 catch 절의 IL 구조
; https://www.sysnet.pe.kr/2/0/13625




C# - Exception Filter 조건(when)을 갖는 catch 절의 IL 구조

예전에 기본적인 try/catch/finally를 포함한 메서드의 분석을 했었습니다.

C# try/catch/finally의 IL 코드 표현
; https://www.sysnet.pe.kr/2/0/11053

이번에는 C# 6부터 추가된 exception filter까지 확장해서 알아보겠습니다. ^^ 이를 위해 간단하게 예제 메서드를 하나 만들고,

public int WhenTest(int n)
{
    try
    {
        n = 50;
    }
    catch (Exception) when (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
    {
        Console.WriteLine(n);
    }

    return n;
}

빌드하면 WhenTest 메서드의 IL 코드는 다음과 같은 식으로 출력됩니다.

1b 30 02 00 3c 00 00 00 05 00 00 11 00 00 1f 32 10 01 00 de 2d 75 19 00 00 01 25 2d 04 26 16 2b 13 26 28 37 00 00 0a 28 38 00 00 0a 16 fe 01 0a 06 16 fe 03 fe 11 26 00 03 28 39 00 00 0a 00 00 de 00 03 0b 2b 00 07 2a 01 10 00 00 01 00 01 00 08 2a 00 0c 09 00 00 00


첫 바이트인 0x1b(0n27)는 다음의 조합입니다.

CorILMethod_InitLocals = 0x10;
CorILMethod_FatFormat = 0x03;
CorILMethod_MoreSects = 0x08;

Fat Header인 경우, 두 번째 바이트인 0x30 바이트는 0xF0과 AND 연산을 한 후 4비트 우측 shift 연산을 하면,

0x30 & 0xF0 == 0x30

0x30 >> 4 
// 0011 0000 0001 1011 >> 12 == 0011

3이 나오고 그것이 Fat Header의 크기가 됩니다. 단지 그 3의 단위가 바이트가 아닌 sizeof(int)로 4바이트이기 때문에 총 3 * 4 = 12 바이트가 Fat Header의 크기입니다.

1b 30 02 00 
3c 00 00 00 
05 00 00 11

Fat Header인 경우, 이후 0x02, 0x00은 short로 0x0002 값이 돼 max stack의 크기를 나타냅니다. 내부적으로 (항상 그런 것은 아니지만) 대략 2개의 Local 변수가 사용된다고 보면 됩니다.

그다음 0x3c, 0x00, 0x00, 0x00은 int 0x0000003c로 읽혀 메서드의 코드 크기가 됩니다. 즉, 12바이트 이후 0x3c(0n60) 바이트는 사용자가 작성한 코드에 해당합니다. 그리고 Header의 남은 0x05, 0x00, 0x00, 0x11은 int로 읽혀 0x11000005가 돼 LocalVarSig를 의미합니다. 이 값으로 .NET Metadata 테이블의 LocalVarSig 영역을 검색하면 해당 메서드의 로컬 변수에 해당하는 타입들의 signature를 알아낼 수 있습니다.

그리고 이후 60바이트는, 헤더에서 밝힌 대로 메서드의 코드가 되는데,

00 00 1f 32 
10 01 00 de 
2d 75 19 00 
00 01 25 2d 
04 26 16 2b 
13 26 28 37 
00 00 0a 28 
38 00 00 0a 
16 fe 01 0a 
06 16 fe 03 
fe 11 26 00 
03 28 39 00 
00 0a 00 00 
de 00 03 0b 
2b 00 07 2a 

이에 대한 해석은 IL 코드 분석을 따르면 됩니다. 간략하게 분석하면 대충 다음과 같이 나옵니다.

L_0000(000000, +0): /* 00 */ nop
L_0001(000001, +1): /* 00 */ nop
L_0002(000002, +1): /* 1f */ ldc.i4.s 0x32
L_0004(000004, +2): /* 10 */ starg.s 0x01
L_0006(000006, +2): /* 00 */ nop
L_0007(000007, +1): /* de */ leave.s 0x2d // L_0036 (offset: 45)
L_0009(000009, +2): /* 75 */ isinst 0x01000019
L_000e(000014, +5): /* 25 */ dup
L_000f(000015, +1): /* 2d */ brtrue.s 0x04 // L_0015 (offset: 4)
L_0011(000017, +2): /* 26 */ pop
L_0012(000018, +1): /* 16 */ ldc.i4.0
L_0013(000019, +1): /* 2b */ br.s 0x13 // L_0028 (offset: 19)
L_0015(000021, +2): /* 26 */ pop
L_0016(000022, +1): /* 28 */ call  //  0x0a000037
L_001b(000027, +5): /* 28 */ call  //  0x0a000038
L_0020(000032, +5): /* 16 */ ldc.i4.0
L_0021(000033, +1): /* fe 01 */ ceq
L_0023(000035, +2): /* 0a */ stloc.0
L_0024(000036, +1): /* 06 */ ldloc.0
L_0025(000037, +1): /* 16 */ ldc.i4.0
L_0026(000038, +1): /* fe 03 */ cgt.un
L_0028(000040, +2): /* fe 11 */ endfilter
L_002a(000042, +2): /* 26 */ pop
L_002b(000043, +1): /* 00 */ nop
L_002c(000044, +1): /* 03 */ ldarg.1
L_002d(000045, +1): /* 28 */ call  //  0x0a000039
L_0032(000050, +5): /* 00 */ nop
L_0033(000051, +1): /* 00 */ nop
L_0034(000052, +1): /* de */ leave.s 0x00 // L_0036 (offset: 0)
L_0036(000054, +2): /* 03 */ ldarg.1
L_0037(000055, +1): /* 0b */ stloc.1
L_0038(000056, +1): /* 2b */ br.s 0x00 // L_003a (offset: 0)
L_003a(000058, +2): /* 07 */ ldloc.1
L_003b(000059, +1): /* 2a */ ret

자, 이제 60바이트 이후의 남은 영역에 대한 조사인데요,

01 10 00 00 
01 00 01 00 
08 2a 00 0c 
09 00 00 00 

첫 4바이트는 Exception Header를 나타내는데,

01 10 00 00

0x01 == Small Format을 의미하고, 그다음 24비트, 즉 3바이트인 0x10, 0x00, 0x00은 3바이트 값으로 0x000010으로 (헤더에 해당하는) -4를 하면 이후의 sector 크기가 나옵니다. 따라서 0x10(0n16) - 4 = 12바이트니까 아래의 내용만큼 읽어낼 수 있습니다.

01 00 01 00 
08 2a 00 0c 
09 00 00 00 

저 12바이트는 Small Clause 1개의 크기에 해당하므로,

typedef struct IMAGE_COR_ILMETHOD_SECT_EH_CLAUSE_SMALL
{
#ifdef _WIN64
    unsigned            Flags         : 16;
#else // !_WIN64
    CorExceptionFlag    Flags         : 16;
#endif
    unsigned            TryOffset     : 16;
    unsigned            TryLength     : 8;  // relative to start of try block
    unsigned            HandlerOffset : 16;
    unsigned            HandlerLength : 8;  // relative to start of handler
    union {
        DWORD       ClassToken;
        DWORD       FilterOffset;
    };
} IMAGE_COR_ILMETHOD_SECT_EH_CLAUSE_SMALL;

일단은, 1개의 catch 문이 있는 것을 의미합니다. 그리고 이것을 분석해 보면 다음과 같습니다.

01 00 (Flags)
01 00 (TryOffset)
08 (Try Length)
2a 00 (HandlerOffset)
0c (HandlerLength)
09 00 00 00 (ClassTokenOrFilterOffset)

Flags는 CorExceptionFlag에 해당하는데,

typedef enum CorExceptionFlag                       // definitions for the Flags field below (for both big and small)
{
    COR_ILEXCEPTION_CLAUSE_NONE,                    // This is a typed handler
    COR_ILEXCEPTION_CLAUSE_OFFSETLEN = 0x0000,      // Deprecated
    COR_ILEXCEPTION_CLAUSE_DEPRECATED = 0x0000,     // Deprecated
    COR_ILEXCEPTION_CLAUSE_FILTER  = 0x0001,        // If this bit is on, then this EH entry is for a filter
    COR_ILEXCEPTION_CLAUSE_FINALLY = 0x0002,        // This clause is a finally clause
    COR_ILEXCEPTION_CLAUSE_FAULT = 0x0004,          // Fault clause (finally that is called on exception only)
    COR_ILEXCEPTION_CLAUSE_DUPLICATED = 0x0008,     // duplicated clause. This clause was duplicated to a funclet which was pulled out of line
} CorExceptionFlag;

따라서 위의 경우 COR_ILEXCEPTION_CLAUSE_FILTER 절임을 의미합니다. 즉, C# 코드로는 when exception filter가 사용된 catch인 것입니다.

COR_ILEXCEPTION_CLAUSE_FILTER 절이기 때문에 "09 00 00 00" 4바이트는 (ClassToken 토큰이 아니라) when 필터링 코드에 해당하는 IL 코드 위치로 0x00000009 값의 위치를 가리키는데요,

L_0000(000000, +0): /* 00 */ nop
...[생략]...
L_0007(000007, +1): /* de */ leave.s 0x2d // L_0036 (offset: 45)
L_0009(000009, +2): /* 75 */ isinst 0x01000019
L_000e(000014, +5): /* 25 */ dup
L_000f(000015, +1): /* 2d */ brtrue.s 0x04 // L_0015 (offset: 4)
L_0011(000017, +2): /* 26 */ pop
...[생략]...
L_0025(000037, +1): /* 16 */ ldc.i4.0
L_0026(000038, +1): /* fe 03 */ cgt.un
L_0028(000040, +2): /* fe 11 */ endfilter
L_002a(000042, +2): /* 26 */ pop
L_002b(000043, +1): /* 00 */ nop
L_002c(000044, +1): /* 03 */ ldarg.1
L_002d(000045, +1): /* 28 */ call  //  0x0a000039
L_0032(000050, +5): /* 00 */ nop
L_0033(000051, +1): /* 00 */ nop
L_0034(000052, +1): /* de */ leave.s 0x00 // L_0036 (offset: 0)
L_0036(000054, +2): /* 03 */ ldarg.1
L_0037(000055, +1): /* 0b */ stloc.1
L_0038(000056, +1): /* 2b */ br.s 0x00 // L_003a (offset: 0)
L_003a(000058, +2): /* 07 */ ldloc.1
L_003b(000059, +1): /* 2a */ ret

따라서 C# 코드의 "catch (Exception) when (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))"에 해당하는 코드로, 그 부분을 해석하면 다음과 같이 번역할 수 있습니다.

if ([ex] is Exception)
{
    if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
    {
        Console.WriteLine(n);
    }
}

그러니까, when exception filter는 단순히 코드로 확장된 유형에 지나지 않는 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 5/22/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  [32]  33  34  35  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
13173정성태11/27/202214406.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/202214109.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
13171정성태11/25/202213356Windows: 214. 윈도우 - 스레드 스택의 "red zone"
13170정성태11/24/202214961Windows: 213. 윈도우 - 싱글 스레드는 컨텍스트 스위칭이 없을까요?
13169정성태11/23/202216403Windows: 212. 윈도우의 Protected Process (Light) 보안 [1]파일 다운로드2
13168정성태11/22/202213405제니퍼 .NET: 31. 제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
13167정성태11/21/202214247.NET Framework: 2070. .NET 7 - Console.ReadKey와 리눅스의 터미널 타입
13166정성태11/20/202214528개발 환경 구성: 651. Windows 사용자 경험으로 WSL 환경에 dotnet 런타임/SDK 설치 방법
13165정성태11/18/202212835개발 환경 구성: 650. Azure - "scm" 프로세스와 엮인 서비스 모음
13164정성태11/18/202215479개발 환경 구성: 649. Azure - 비주얼 스튜디오를 이용한 AppService 원격 디버그 방법
13163정성태11/17/202215642개발 환경 구성: 648. 비주얼 스튜디오에서 안드로이드 기기 인식하는 방법
13162정성태11/15/202216908.NET Framework: 2069. .NET 7 - AOT(ahead-of-time) 컴파일 [1]
13161정성태11/14/202215327.NET Framework: 2068. C# - PublishSingleFile로 배포한 이미지의 역어셈블 가능 여부 (난독화 필요성) [4]
13160정성태11/11/202215923.NET Framework: 2067. C# - PublishSingleFile 적용 시 native/managed 모듈 통합 옵션
13159정성태11/10/202218640.NET Framework: 2066. C# - PublishSingleFile과 관련된 옵션 [3]
13158정성태11/9/202214314오류 유형: 826. Workload definition 'wasm-tools' in manifest 'microsoft.net.workload.mono.toolchain' [...] conflicts with manifest 'microsoft.net.workload.mono.toolchain.net7'
13157정성태11/8/202215380.NET Framework: 2065. C# - Mutex의 비동기 버전파일 다운로드1
13156정성태11/7/202217632.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점파일 다운로드1
13155정성태11/4/202215497디버깅 기술: 183. TCP 동시 접속 (연결이 아닌) 시도를 1개로 제한한 서버
13154정성태11/3/202216244.NET Framework: 2063. .NET 5+부터 지원되는 GC.GetGCMemoryInfo파일 다운로드1
13153정성태11/2/202217299.NET Framework: 2062. C# - 코드로 재현하는 소켓 상태(SYN_SENT, SYN_RECV)
13152정성태11/1/202216394.NET Framework: 2061. ASP.NET Core - DI로 추가한 클래스의 초기화 방법 [1]
13151정성태10/31/202215684C/C++: 161. Windows 11 환경에서 raw socket 테스트하는 방법파일 다운로드1
13150정성태10/30/202214012C/C++: 160. Visual Studio 2022로 빌드한 C++ 프로그램을 위한 다른 PC에서 실행하는 방법
13149정성태10/27/202214645오류 유형: 825. C# - CLR ETW 이벤트 수신이 GCHeapStats_V1/V2에 대해 안 되는 문제파일 다운로드1
13148정성태10/26/202215350오류 유형: 824. msbuild 에러 - error NETSDK1005: Assets file '...\project.assets.json' doesn't have a target for 'net5.0'. Ensure that restore has run and that you have included 'net5.0' in the TargetFramew
... 31  [32]  33  34  35  36  37  38  39  40  41  42  43  44  45  ...