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

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13882정성태2/10/2025525스크립트: 70. 파이썬 - oracledb 패키지 연동 시 Thin / Thick 모드
13881정성태2/7/2025647닷넷: 2316. C# - Port I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13880정성태2/5/2025731오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/2025875오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/2025895오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20251051닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20251211닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20251197스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20251152스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20251083디버깅 기술: 217. WinDbg - PCI 장치 열거
13872정성태1/23/20251067오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20251177Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20251251개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20251270개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20251211Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20251325오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20251332개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20251422오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20251363Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20251302Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20251258Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20251769Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20251702디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20251789디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
13858정성태1/8/20251853개발 환경 구성: 738. PowerShell - 원격 호출 시 "powershell.exe"가 아닌 "pwsh.exe" 환경으로 명령어를 실행하는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...