Microsoft MVP성태의 닷넷 이야기
닷넷: 2262. C# - Exception Filter 조건(when)을 갖는 catch 절의 IL 구조 [링크 복사], [링크+제목 복사],
조회: 9091
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... 136  137  138  139  140  141  142  [143]  144  145  146  147  148  149  150  ...
NoWriterDateCnt.TitleFile(s)
1479정성태8/14/201325187오류 유형: 183. IIS - 바인딩 추가 시 Object reference not set to an instance of an object 오류 [5]
1478정성태8/14/201328494오류 유형: 182. 윈도우 정품 활성화 오류 - 0x80070426
1477정성태8/14/201327340VC++: 71. codeplex의 Project Austin - 실감나게 책장 넘기는 표현
1476정성태8/13/201335823디버깅 기술: 55. Windbg - 윈도우 핸들 테이블 (2)
1475정성태8/12/201334936.NET Framework: 377. 프로세스가 종료된 후에도 소켓이 살아있다면?파일 다운로드1
1474정성태8/10/201330990오류 유형: 181. 윈도우 8 - WmiPrvSE.exe 프로세스가 CPU 소비하는 현상
1473정성태8/8/201327797VC++: 70. Win32 socket이 Thread-safe할까? [1]파일 다운로드1
1472정성태8/7/201326244.NET Framework: 376. .NET 2.0의 유니코드 관련 문자열 비교 오류
1471정성태8/7/201331011개발 환경 구성: 193. .aspx 확장자 대신 .html 확장자를 사용하는 방법
1470정성태8/6/201327001오류 유형: 180. DISM.exe 0xc1510111 실행 오류
1469정성태8/6/201324062.NET Framework: 375. System.Net.Sockets.Socket이 Thread-safe할까? [2]파일 다운로드1
1468정성태8/6/201322213오류 유형: 179. IIS - No connection could be made because the target machine actively refused it 127.0.0.1:80
1467정성태8/5/201325651Java: 16. IE에 로드된 Java Applet의 다운로드 위치를 확인하는 방법
1466정성태7/27/201331237.NET Framework: 374. C#과 비교한 C++ STL vector 성능 [7]파일 다운로드1
1465정성태7/18/201334561기타: 33. C:\Windows\Installer 폴더의 용량 줄이기 [3]
1464정성태7/15/201322822오류 유형: 178. Visual Studio 2012 Express - ImportCardinalityMismatchException
1463정성태7/15/201323468오류 유형: 177. [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
1462정성태7/5/201326784VC++: 69. geek스러운 C/C++ 퀴즈 문제 [2]
1461정성태6/27/201343329.NET Framework: 373. C# 문자열의 인코딩이란?
1460정성태6/17/201325181.NET Framework: 372. PerformanceCounter - Category does not exist. [1]
1459정성태6/15/201328815Windows: 74. 한글 키가 아닌 영문 키를 기본으로 선택하는 방법 [5]
1458정성태6/13/201329669.NET Framework: 371. CAS Lock 방식이 과연 성능에 얼마나 도움이 될까요? [1]파일 다운로드1
1457정성태6/13/201325846개발 환경 구성: 192. "Probabilistic Programming and Bayesian Methods for Hackers" 예제 코드 실행 방법
1456정성태6/5/201334519.NET Framework: 370. C# - WebKit .NET 사용 [2]파일 다운로드1
1455정성태6/1/201328293.NET Framework: 369. ThreadPool.QueueUserWorkItem의 실행 지연 [4]파일 다운로드1
1454정성태5/31/201326329Java: 15. Java 7 Control Panel 실행시키는 방법
... 136  137  138  139  140  141  142  [143]  144  145  146  147  148  149  150  ...