X86 32비트 어셈블리어 소스코드 예제를 통해서 TEXTREL 문제를 확인해보고, 이를 TEXTREL 문제 없는 어셈블리어 소스를 만들어보자. 먼저 다음과 같은 간단한 소스코드 예제를 보자.

#include <stdio.h>
int main() {
   puts("Hello World\n");
   return 0;
}

이 소스를 clang으로 컴파일하고, objconv를 통해 NASM/YASM 소스코드로 변환시켜 조금 정리하면 다음과 같다. (clang -m32 -O2 -c 옵션으로 컴파일)

global main: function
extern puts

SECTION .text
main:
        sub     esp, 12
        mov     dword [esp], .str
        call    puts
        xor     eax, eax
        add     esp, 12
        ret
; main End of function

SECTION .data

.str:
        db "Hello World", 0xa, 0x0

스택 조작하는 부분을 더 간단히 고쳐보면 다음과 같다.

global main: function
extern puts

SECTION .text
main:
        mov     eax, .str
        push    eax
        call    puts
        add     esp, 4
        xor     eax, eax
        ret

SECTION .data

.str:
        db "Hello World", 0xa, 0x0

이를 my.asm로 저장하고 yasm -fnasm my.asm으로 컴파일 후에 gcc -m32 my.o 명령으로 링크를 하면 실행이 잘 됨을 확인할 수 있다

인라인 어셈블리에 익숙해지려면 AT&T 스타일의 어셈블리어도 알아할 것이므로 -S 옵션으로 어셈블리어 소스를 얻고, 이를 정리해보면 다음과 같다.

        .text
        .globl  main
        .align  16
main:
        movl    $.str, %eax
        push    %eax
        calll   puts
        addl    $4, %esp
        xorl    %eax, %eax
        retl

        .section        .data
        .align  16
.str:
        .asciz  "Hello World"

일대일 대응이므로 이해하는데 어렵지 않을 것이다. 이 소스는 my2.s로 저장한 후에 gcc -m32 my2.s로 컴파일하면 실행이 잘 됨을 확인할 수 있다.

이렇게 얻어진 어셈블리어 소스를 오브젝트 파일로 만든 후에 공유 라이브러리를 만들면 어떻게 될까?
다음과 같은 명령으로 공유라이브러리를 얻을 수 있으며, TEXREL 문제 역시 확인할 수 있다.

$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my2.so -o /tmp/my2.so my.o
/usr/bin/ld: my.o: warning: relocation in readonly section `.text'
/usr/bin/ld: warning: creating a DT_TEXTREL in a shared object.

그렇다면 이와 같은 문제의 어셈블리어 소스의 TEXTREL 문제를 어떻게 해결할 수 있을까?

함수의 리로케이션

우선 objdump -r 명령을 통해 리로케이션 정보를 살펴보자. (readelf -r 명령과 거의 동일)

$ objdump -r my.o

my.o:     file format elf32-i386

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000001 R_386_32          .data
00000007 R_386_PC32        puts

puts 함수의 리로케이션 정보를 고치기 위해서는 NASM의 경우 메뉴얼에 나온것처럼 다음과 같이 고치면 함수의 리로케이션 문제가 해결된다. 즉 함수 호출을 call puts로 하는 대신에 call puts wrt ..plt라고 해준다.

global main: function
extern puts

SECTION .text
main:
        mov     eax, .str
        push    eax
        call    puts wrt ..plt
        add     esp, 4
        xor     eax, eax
        ret

SECTION .data

.str:
        db "Hello World", 0xa, 0x0

이렇게 고친 후에 yasm -f elf my.asm으로 컴파일하고, objdump -r 명령으로 확인해보면 뭔가 달라졌음을 확인할 수 있다.

$ objdump -r my.o

my.o:     file format elf32-i386

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000001 R_386_32          .data
00000007 R_386_PLT32       puts

즉, 리로케이션 테이블에 있는 puts 엔트리의 오프셋은 전혀 변화가 없는데, 리로케이션 타입이 R_386_PLT32로 바뀌었으며, 함수 puts에 대한 리로케이션 문제는 수정된 것이다.

AT&T 스타일의 소스의 경우는 다음과 같은 식으로 고쳐야 한다.

        .text
        .globl  main
        .align  16
main:
        movl    $.str, %eax
        push    %eax
        calll   puts@PLT
        addl    $4, %esp
        xorl    %eax, %eax
        retl

        .section        .data
        .align  16
.str:
        .asciz  "Hello World"

YASM/NASM에서는 조금 헷갈리게 만드는 wrt ..plt라는 지시자를 썼지만, AT&T 스타일에서는 왠지 한결 쉬운듯한 @PLT를 사용하고 있다. 이 경우 역시 gcc -m32 -c 명령으로 컴파일한 후에 gcc로 공유 라이브러리를 생성시켜보면 여전히 TEXTREL문제가 남아있음을 확인할 수 있는데, 이는 함수에 대한 리로케이션 뿐만 아니라, 데이터에 대한 리로케이션 정보도 바꿔줘야 하기 때문이다.

어셈블리어 소스는 @PLT 지시자를 통해서 고쳤으나, objdump -d를 통해서 바이너리 코드를 살펴보면 바뀌기 전 코드와 완전히 일치한다. @PLT같은 지시자는 리로케이션 테이블의 정보를 바꿔주는 역할을 할 뿐, 실제 실행 코드 (.text 섹션내 실행 코드) 자체는 변화가 없다.

리로케이션 테이블을 readelf -r 명령을 통해서 보면 다음과 같다.

$ readelf -r my.o

Relocation section '.rel.text' at offset 0x54 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000001  00000201 R_386_32          00000000   .data
00000007  00000604 R_386_PLT32       00000000   puts

오브젝트 파일을 xxd로 덤프해서 바이너리 파일을 비교해보면 다음과 같은 차이가 있는 것을 볼 수 있다. (아래쪽 변경점은 소스파일의 파일 이름이 fa.asm 에서 fb.asm으로 변한 정보)

--- a   2017-03-10 18:54:40.016601488 +0900
+++ b   2017-03-10 18:54:43.364574036 +0900
@@ -4,11 +4,11 @@
 00000030: 0700 0100 0000 0000 0000 0000 0000 0000  ................
 00000040: b800 0000 0050 e8fc ffff ff83 c404 31c0  .....P........1.
 00000050: c300 0000 0100 0000 0102 0000 0700 0000  ................
-00000060: 0406 0000 4865 6c6c 6f20 576f 726c 6421  ....Hello World!
+00000060: 0206 0000 4865 6c6c 6f20 576f 726c 6421  ....Hello World!
 00000070: 0a00 0000 002e 7465 7874 002e 6461 7461  ......text..data
 00000080: 002e 7265 6c2e 7465 7874 002e 7374 7274  ..rel.text..strt
 00000090: 6162 002e 7379 6d74 6162 002e 7368 7374  ab..symtab..shst
-000000a0: 7274 6162 0000 0000 0066 612e 6173 6d00  rtab.....fa.asm.
+000000a0: 7274 6162 0000 0000 0066 622e 6173 6d00  rtab.....fb.asm.
 000000b0: 6d61 696e 0070 7574 7300 0000 0000 0000  main.puts.......
 000000c0: 0000 0000 0000 0000 0000 0000 0100 0000  ................
 000000d0: 0000 0000 0000 0000 0400 f1ff 0000 0000  ................

데이터 리로케이션

다음은 데이터 리로케이션 정보를 넣어줄 차례이다. 그런데 이 경우는 x86_32비트의 경우 문제가 약간 복잡한데, 이유는 차차 설명하기로 한다.

먼저 64비트의 경우를 살펴보자. hello world 프로그램을 clang -O2 -S 옵션으로 소스를 얻고 정리를 해보면 다음과 같다.

        .text
        .globl  main
main:
        movl    $.str, %edi
        callq   puts
        xorl    %eax, %eax
        retq

        .section        .rodata
.str:
        .asciz  "Hello World"

여기서 movl $.str, %edi 코드는 .str 문자열의 주소값($.str)을 %edi 레지스터에 넣으라는 것이다. 이 명령은 leal .str, %edi와 하는 일이 같다.

64비트의 경우에는 함수 호출 규약이 더 간단한데, 스택으로 호출 인자를 넘기는 것이 아니라 rdi, rsi 등의 레지스터를 통해 인자를 넘기고 있다. 따라서 push 혹은 pop을 통해 인자를 넘기지 않고 곧바로 edi, esi 레지스터를 수정하게 된다.

이 프로그램의 리로케이션 문제를 해결하려 하면 다음과 같이 바꿔주어야 한다.

        .text
        .globl  main
main:
        leal    .str(%rip), %edi
        callq   puts@PLT
        xorl    %eax, %eax
        retq

        .section        .rodata
.str:
        .asciz  "Hello World"

32비트에서처럼 함수의 경우에는 @PLT 지시자를 넣었으나, 데이터 섹션의 .str 주소를 넘기는 부분은 leal .str(%rip), %edi를 사용했다.
이것은 단순히 지시자를 사용한 것이 아니며, X86_64(AMD64)에서 새로 도입된 레지스터 %rip를 사용해서 .str 문자열 주소를 넘겨준 것이다.

AT&T의 문법이 헷갈릴 수 있으니 이에 대응하는 YASM/NASM 어셈블리어로 살펴보자.

default rel

global main

extern puts

SECTION .text

main:
        lea     edi, [rel .str]
        call    puts wrt ..plt
        xor     eax, eax
        ret

SECTION .rodata

.str:
        db "Hello World"

default rel등등이 포함된 것을 제외하고는 32비트/64비트 프로그램 소스가 거의 같고, .str 문자열 주소를 넘겨주는 부분이 다른 것을 볼 수 있다.

문자열의 주소는 .str이며, .str의 주소의 내용은 [.str]인데, lea eax, [.str]이라고 쓰면 .str의 주소값을 넘겨주라는 것이다. (NASM/YASM에서 사용할 수 있는 몇몇 주소 지정 방식은 다음 링크를 통해서 볼 수 있다. https://www.tortall.net/projects/yasm/manual/html/nasm-effaddr.html#nasm-effaddr-riprel)

이렇게 문자열 .str의 주소를 넘겨주는 코드에 rel이라는 지시자를 넣으면 리로케이션 문제가 없는 오브젝트 파일이 생성된다. (NASM/YASM에서는 rip 레지스터를 직접 사용하면 오류가난다.) 이렇게 해서 생성된 코드의 바이트수도 조금 다르다는 것을 다음과 같이 확인할 수 있다.

$ objdump -d nopic.o

ffa-nopic.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <main>:
   0:   8d 3c 25 00 00 00 00    lea    0x0,%edi
   7:   e8 00 00 00 00          callq  c <main+0xc>
   c:   31 c0                   xor    %eax,%eax
   e:   c3                      retq

$ objdump -d pic.o # 수정된 PIC 코드의 경우

ffa.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <main>:
   0:   8d 3d 00 00 00 00       lea    0x0(%rip),%edi        # 6 <main+0x6>
   6:   e8 00 00 00 00          callq  b <main+0xb>
   b:   31 c0                   xor    %eax,%eax
   d:   c3                      retq

함수와는 다르게, 데이터의 주소를 상대적 주소로 바꿔주기 위해서 명령 코드 자체가 조금 바뀐 것을 알 수 있는데, 64비트에서 데이터 주소를 상대적 주소로 바꿔주기 위해서 %rip 레지스터를 사용한다. %rip 레지스터는 X86_32에서는 %eip이며, 16비트 32비트의 경우 %eip 어드레스의 값을 손쉽게 불러오지 못하였으나, X86_64(AMD64)부터는 %rip를 불러서 상대적 주소를 쉽게 계산할 수 있게 된 것이다.

그렇다면 X86 32비트에서는 데이터의 상대주소를 어떻게 구할까?

Call Pop 트릭

콜팝은 콜라+팝콘의 뜻이 아니고, 32비트에서 %eip 레지스터의 값을 가져오는 트릭이다. call + pop을 통해 %eip 레지스터 값을 읽는 방식을 구현할 수 있다. 32비트에서도 명령 카운트 레지스터가 존재하지만, 이것은 직접 읽기가 불가능한 레지스터이다. 그런데 함수를 콜하게 되면 스택에 리턴할 주소를 저장한다는 사실을 알고 있다. 스택에 저장되는 리턴할 주소가 바로 명령 카운터 레지스터 %eip의 값인 셈이다. 또한, 리턴할 주소는 바로 다음 명령이 실행될 위치이며, 이 경우 local:주소의 값이 된다. 따라서 아래와 같이 하면 %ebx 레지스터에 local:의 실제 주소값이 저장될 것이다.

    call local
local:
    pop %ebx

pop 대신에 mov (esp), %ebx라고 해도 된다. 그렇다면 이렇게 얻어진 %ebx 값은 local:의 실제 메모리에 올라간 진짜 주소가 된다는 것인데, 그렇다면 데이터가 적재된 곳의 주소 위치는 어떻게 구하게 될까? 64비트에서 lea .str(%rip), %eax라고 하면 되었듯이, %rip 대신에 %eip가 저장된 위치인 %ebx를 사용하여 leal .str(%ebx), %eax 라고 하면 될 것 같은데, 실제로는 이런 메커니즘을 지원하지 않으며, 다음과 같은 조금 아리송한 코드가 실제 사용된다. 즉,

    call local
local:
    pop %ebx
    leal .str(%ebx), %eax

라고 해야 하는 것이 아니라 다음과 같이 한다

    call local
local:
    pop %ebx
local2:
    addl $_GLOBAL_OFFSET_TABLE_ + (local2 - local), %ebx
    leal .str@GOTOFF(%ebx), %eax

알쏭달쏭한 이 코드를 gdb로 파헤쳐보면 내막을 알 수 있지만, 실제로 _GLOBAL_OFFSET_TABLE_ 이라는 주소의 값은 프로그램이 적재되기 이전까지 알 수 없는 값이고, 소스코드상의 _GLOBAL_OFFSET_TABLE_은 조금 다르게 해석 되어진다. (이 부분은 아래에서 살펴보겠다.) 소스를 컴파일해서 얻어진 오브젝트 파일은 $_GLOBAL_OFFSET_TABLE_값을 아직 알지 못하고, 최종 실행파일은 링커에 의해 해석되어진 후에 GLOBAL OFFSET TABLE이 만들어지게 되어 비로소 GLOBAL_OFFSET_TABLE을 알게 된다.
본인도 이 부분이 제대로 이해되지 않아서 어려워했으나, gdb를 통해 내막을 살펴보고서야 이해하게 되었다.

_GLOBAL_OFFSET_TABLE은 변수? 상수?

우선 다음의 소스코드를 살펴보자. 이것은 hello world 프로그램의 PIC 버전이다. clang -O2 -fPIC -m32 -S 옵션으로 컴파일해서 소스를 얻고 이를 정리한 것이다.

        .text
        .globl  main
main:
        call    .tmp0
.tmp0:
        popl    %ebx
.tmp1:
        addl    $_GLOBAL_OFFSET_TABLE_+(.tmp1-.tmp0), %ebx
        leal    .str@GOTOFF(%ebx), %eax
        movl    $_GLOBAL_OFFSET_TABLE_, %ebx ; 디버그용 코드
        movl    $_GLOBAL_OFFSET_TABLE_, %ebx ; 디버그용 코드
        push    %eax
        call    puts@PLT
        
        add     $4, %esp
        xorl    %eax, %eax
        retl

        .section        .rodata
.str:
        .asciz  "Hello World"

$_GLOBAL_OFFSET_TABLE값을 알기 위해서 중간에 디버그 코드를 넣었다. 이를 컴파일해서 오브젝트 파일 및 실행파일을 얻었다. 이를 objdump -d 명령으로 살펴보면 main 함수가 다음과 같다.

objdump -d 목적파일

00000000 <main>:
   0:   e8 00 00 00 00          call   5 <.tmp0>

00000005 <.tmp0>:
   5:   5b                      pop    %ebx

00000006 <.tmp1>:
   6:   81 c3 03 00 00 00       add    $0x3,%ebx
   c:   8d 83 00 00 00 00       lea    0x0(%ebx),%eax
  12:   bb 01 00 00 00          mov    $0x1,%ebx
  17:   bb 01 00 00 00          mov    $0x1,%ebx
  1c:   50                      push   %eax
  1d:   e8 fc ff ff ff          call   1e <.tmp1+0x18>
  22:   83 c4 04                add    $0x4,%esp
  25:   31 c0                   xor    %eax,%eax
  27:   c3                      ret

위의 내용을 잘 살펴보면 $_GLOBAL_OFFSET_TABLE_ 값이 들어가야 할 자리가 $0x1 이라는 값이 들어있다. 또한, $_GLOBAL_OFFSET_TABLE_+(.tmp1-.tmp0)가 들어가야 할 자리는 두 주소의 차이 (.tmp1-.tmp0) 값이 1이므로 0x02이어야 할 것 같은데 이상하게 $0x03이 들어있다. 그러면 실행파일을 덤프해보면 어떤가 살펴보자.

objdump -d 실행파일

...(생략)
0804840b <main>:
 804840b:       e8 00 00 00 00          call   8048410 <.tmp0>

08048410 <.tmp0>:
 8048410:       5b                      pop    %ebx

08048411 <.tmp1>:
 8048411:       81 c3 f0 1b 00 00       add    $0x1bf0,%ebx
 8048417:       8d 83 c0 e4 ff ff       lea    -0x1b40(%ebx),%eax
 804841d:       bb e3 1b 00 00          mov    $0x1be3,%ebx
 8048422:       bb de 1b 00 00          mov    $0x1bde,%ebx
 8048427:       50                      push   %eax
 8048428:       e8 b3 fe ff ff          call   80482e0 <puts@plt>
 804842d:       83 c4 04                add    $0x4,%esp
 8048430:       31 c0                   xor    %eax,%eax
 8048432:       c3                      ret
...(생략)
Disassembly of section .got.plt:

0804a000 <_GLOBAL_OFFSET_TABLE_>:
 804a000:       14 9f                   adc    $0x9f,%al
 804a002:       04 08                   add    $0x8,%al

실행파일에서는 $_GLOBAL_OFFSET_TABLE_이 들어갈 위치의 값이 모두 다른 값으로 채워져 있으며, $_GLOBAL_OFFSET_TABLE_+(.tmp1-.tmp0) 값에는 $0x1bf0(7152)가 들어가고, $_GLOBAL_OFFSET_TABLE_값이 들어갈 줄 알았던 곳은 각각 $0x1be3(7139) , $0x1bde(7134) 값이 채워져 있다. 그리고 정작 _GLOBAL_OFFSET_TABLE_ 주소는 0x0804a000값이다.
실제로 상수인줄 알았던 소스코드상에 들어간 $_GLOBAL_OFFSET_TABLE_ 값은 링커에 의해 고정된 값으로 해석되는 것이 아니라 .data 섹션과의 오프셋값으로 해석되어지고 있는 것이다.

따라서 실제 GLOBAL_OFFSET_TABLE 즉 실행파일이 메모리에 올라갔을 때에 .data 세그먼트의 위치를 가리키는 값은 다음과 같이 계산되어진다.

        GLOBAL_OFFSET_TABLE의 실제 위치 = 현재 실행 코드의 %eip + 현재 실행 코드와 GLOBAL_OFFSET_TABLE 주소와 오프셋(여기서는 $_GLOBAL_OFFSET_TABLE_)

아무튼 이 과정은 GNU as + GND ld의 합작 과정인 것인데, YASM/NASM에서는 이마져도 약간 다르게 보이지만 원리는 같다. 다음 코드는 YASM/NASM에서 GLOBAL_OFFSET_TABLE를 구하는 코드이다.

global main: function
extern puts
extern _GLOBAL_OFFSET_TABLE_ ; YASM/NASM에서는 이를 선언해주어야 한다.

SECTION .text
main:
        call .get_got
.get_got:
        pop     ebx
.tmp:
        add     ebx, _GLOBAL_OFFSET_TABLE_ + .tmp - .get_got ; AT&T 스타일의 어셈블리어와 같은 방식
        ;add    ebx, _GLOBAL_OFFSET_TABLE_ + $$ - .get_got wrt ..gotpc ; NASM/YASM 메뉴얼에 나와있는 방식.
        lea     eax, [.str + ebx wrt ..gotoff]
        push    eax
        call    puts wrt ..plt
        add     esp, 4
        xor     eax, eax
        ret

SECTION .data

.str:
        db "Hello World", 0xa, 0x0

이렇게 하여 이 소스를 컴파일하여 오브젝트 파일의 리로케이션 정보를 보면 다음과 같게 되며 TEXTRELs 문제가 없게 된다.

$ objdump -r test.o

test.o:     file format elf32-i386

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000008 R_386_GOTPC       _GLOBAL_OFFSET_TABLE_
0000000e R_386_GOTOFF      .data
00000014 R_386_PLT32       puts

※참고:

http://nullprogram.com/blog/2016/12/23/ - GLOBAL_OFFSET_TABLE 및 x86에서 리로케이션에 대한 설명이 되어있다.

by dumpcookie 2017. 3. 11. 09:40

지금에야 64비트를 주로 쓰는 환경이므로 x86 32비트 환경에서 Text relocation문제가 크게 문제될 만한 사항은 아니지만, 안드로이드 6.0 이후로는 x86/arm 32비트의 경우, TEXTREL 문제가 있는 공유 라이브러리를 사용하는 경우 아예 실행조차 되지 않기때문에 (API 23 이상으로 빌드된 APK의 경우는 실행 안됨) 이 문제를 정리 차원에서 적도록 하겠다.

예를 들어 x264 / mpg123 / FFmpeg 등등의 꽤 널리 알려진 오픈소스 프로젝트의 경우, x86 32비트로 컴파일을 하면 TEXTRELs 문제가 있게 된다. 문제있는 공유라이브러리는 어떻게 찾을 수 있을까?

먼저 TEXTRELs 문제가 있는 라이브러리는 readelf, scanelf 등을 사용하여 찾을 수 있다.

예를 들어 FFmpeg의 libavcodec.so는 TEXTRELs 문제가 있으며 다음과 scanelf -T 명령을 이용하면 다음과 같은 식의 매우 긴 출력을 한다.

https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide 참고

 $ scanelf -T libavcodec.so
 TYPE   TEXTRELS FILE
  libavcodec.so: (memory/data?) [0x845599] in (optimized out: previous put_cavs_qpel8_h_mmxext) [0x845560]
  libavcodec.so: (memory/data?) [0x8455EB] in (optimized out: previous put_cavs_qpel8_h_mmxext) [0x845560]
  libavcodec.so: (memory/data?) [0x845669] in (optimized out: previous avg_cavs_qpel8_h_mmxext) [0x845630]
  libavcodec.so: (memory/data?) [0x8456BB] in (optimized out: previous avg_cavs_qpel8_h_mmxext) [0x845630]
  libavcodec.so: (memory/data?) [0x845771] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
  libavcodec.so: (memory/data?) [0x84577B] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
  libavcodec.so: (memory/data?) [0x8457A8] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
  libavcodec.so: (memory/data?) [0x8457C7] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
  libavcodec.so: (memory/data?) [0x8457D1] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
  libavcodec.so: (memory/data?) [0x8457FE] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
  libavcodec.so: (memory/data?) [0x84581D] in (optimized out: previous avg_cavs_qpel8or16_v1_mmxext) [0x845700]
....

공유 라이브러리는 이미 리로케이션이 되어서 구체적으로 어떤 오브젝트 파일의 오류가 있는지는 알 수 없으나 TEXTRELs 문제가 있는지 없는지 정도는 간단히 파악할 수 있다.

readelf -a 혹은 readelf -d 명령을 사용하면 다음과 같은 더욱 요약된 정보를 볼 수 있다. -d 옵션은 --dynamic 옵션과 같고, dynamic 섹션 정보를 보여준다. -a 옵션은 모든 정보를 출력한다.

$ readelf -d x86/libavcodec.so

Dynamic section at offset 0xc3d81c contains 36 entries:
  Tag        Type                         Name/Value
 0x00000003 (PLTGOT)                     0xc3eb58
 0x00000002 (PLTRELSZ)                   2328 (bytes)
 0x00000017 (JMPREL)                     0x57748
 0x00000014 (PLTREL)                     REL
 0x00000011 (REL)                        0x20b90
 0x00000012 (RELSZ)                      224184 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   27939
 0x00000006 (SYMTAB)                     0x158
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000005 (STRTAB)                     0xba18
 0x0000000a (STRSZ)                      60344 (bytes)
 0x00000004 (HASH)                       0x1a5d0
 0x00000001 (NEEDED)                     Shared library: [libavutil.so]
 0x00000001 (NEEDED)                     Shared library: [libswresample.so]
 0x00000001 (NEEDED)                     Shared library: [libz.so]
 0x00000001 (NEEDED)                     Shared library: [libmp3lame.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x0000000e (SONAME)                     Library soname: [libavcodec.so]
 0x0000001a (FINI_ARRAY)                 0xc3cf94
 0x0000001c (FINI_ARRAYSZ)               8 (bytes)
 0x00000019 (INIT_ARRAY)                 0xc3e818
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x00000016 (TEXTREL)                    0x0
 0x00000010 (SYMBOLIC)                   0x0
 0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW
 0x6ffffffb (FLAGS_1)                    Flags: NOW
 0x6ffffff0 (VERSYM)                     0x1f41c
 0x6ffffffc (VERDEF)                     0x20b34
 0x6ffffffd (VERDEFNUM)                  1
 0x6ffffffe (VERNEED)                    0x20b50
 0x6fffffff (VERNEEDNUM)                 2
 0x00000000 (NULL)                       0x0

여기서 0x00000016 (TEXTREL) 0x0에 해당하는 부분이 TEXTREL 문제가 있는 라이브러리라는 것을 보여준다.

scanelf 혹은 readelf를 통해서 TEXTRELs문제를 어느정도 파악했다고 하자. 그렇다면 구체적으로 어떤 소스가 TEXTRELs문제를 일으키는지는 어떻게 알 수 있을까?
우선 이 문제를 원본 소스가 있을때를 가정으로 한다면 의외로 어렵지 않게 찾아낼 수 있다.

x86 32비트 라이브러리 하나를 예로 들어보자. 여기서는 FFmpeg라이브러리를 골라보았다. FFmpeg 라이브러리를 32비트 x86용 공유 라이브러리 형태로 컴파일한 후에, 각각의 오브젝트 파일에 대해서 살펴보도록 하자.

readelf를 사용하면 공유라이브러리뿐만 아니라 오브젝트파일의 정보도 볼 수 있는데, 특히 strip되지 않는 오브젝트 파일의 경우에는 다음과 같은 정보를 볼 수 있다. FFmpeg 라이브러리의 avcodec 모듈 소스중에 하나인 gif.c를 컴파일해서 얻어진 오브젝트 파일에 대한 정보를 readelf -r 명령으로 보면 다음과 같다.

Relocation section '.rel.text.pick_palette_entry' at offset 0xe98c contains 5 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000000c  00004102 R_386_PC32        00000000   __x86.get_pc_thunk.bx
00000012  0000420a R_386_GOTPC       00000000   _GLOBAL_OFFSET_TABLE_
0000001f  00004303 R_386_GOT32       00000000   __stack_chk_guard
000000cb  00004303 R_386_GOT32       00000000   __stack_chk_guard
000000f4  00004402 R_386_PC32        00000000   __stack_chk_fail_local

Relocation section '.rel.text.gif_encode_close' at offset 0xe9b4 contains 6 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000003  00004102 R_386_PC32        00000000   __x86.get_pc_thunk.bx
00000009  0000420a R_386_GOTPC       00000000   _GLOBAL_OFFSET_TABLE_
0000001f  00004504 R_386_PLT32       00000000   av_freep
0000002a  00004504 R_386_PLT32       00000000   av_freep
00000042  00004604 R_386_PLT32       00000000   av_frame_free
0000004a  00004504 R_386_PLT32       00000000   av_freep

Relocation section '.rel.text.put_bits' at offset 0xe9e4 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000000a  00004102 R_386_PC32        00000000   __x86.get_pc_thunk.bx
00000010  0000420a R_386_GOTPC       00000000   _GLOBAL_OFFSET_TABLE_
0000006a  00002a09 R_386_GOTOFF      00000000   .LC2
0000007a  00004704 R_386_PLT32       00000000   av_log
...(생략)

복잡해보이지만, 이 오브젝트 파일에는 그 심볼 타입이 R_386_PC32, R_386_GOTPC, R_386_GOTOFF, R_386_PLT32등등이 있다는 것 정도를 알 수 있다. c언어로 작성된 소스코드로 얻어진 오브젝트 파일은 (이 경우 -fPIC 옵션으로 컴파일 되어) TEXRELs문제가 없는 경우이다. 반면, x86에 최적화된 x86/fft.asm 어셈블리어 소스를 컴파일해서 얻은 오브젝트 파일의 경우에는 readelf -r 명령 출력이 다음과 같으며, 이 경우는 TEXTRELs 문제가 있는 경우이다.

$ readelf -r  fft.o

Relocation section '.rel.text' at offset 0x2db4 contains 273 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000015  0000a201 R_386_32          00000000   .rodata
0000001e  0000a201 R_386_32          00000000   .rodata
0000003a  0000a201 R_386_32          00000000   .rodata
00000052  0000a201 R_386_32          00000000   .rodata
000000a6  0000a201 R_386_32          00000000   .rodata
000000db  0000a201 R_386_32          00000000   .rodata
000000e4  0000a201 R_386_32          00000000   .rodata
00000100  0000a201 R_386_32          00000000   .rodata
00000118  0000a201 R_386_32          00000000   .rodata
00000148  0000a201 R_386_32          00000000   .rodata
00000150  0000a201 R_386_32          00000000   .rodata
000001f1  0000a201 R_386_32          00000000   .rodata
00000232  0000a201 R_386_32          00000000   .rodata
0000023a  0000a201 R_386_32          00000000   .rodata
0000028a  0000a701 R_386_32          00000000   ff_cos_32
00000292  0000a701 R_386_32          00000000   ff_cos_32
00000393  0000a201 R_386_32          00000000   .rodata
000003d3  0000a201 R_386_32          00000000   .rodata
00000411  0000a201 R_386_32          00000000   .rodata
...(중략)
0000176c  0000a701 R_386_32          00000000   ff_cos_32
0000179e  0000a801 R_386_32          00000000   ff_cos_64
000017d0  0000a901 R_386_32          00000000   ff_cos_128
00001800  0000aa01 R_386_32          00000000   ff_cos_256
00001830  0000ab01 R_386_32          00000000   ff_cos_512
00001860  0000ac01 R_386_32          00000000   ff_cos_1024
00001890  0000ad01 R_386_32          00000000   ff_cos_2048
000018c0  0000ae01 R_386_32          00000000   ff_cos_4096
...(생략)

위에서 나오는 ff_cos_* 심볼은 fft.asm 소스상에서 .data 섹션에 들어가는 여러 상수들이다. 이 데이터의 타입이 R_386_32라고 나오고 있다. 바로 이러한 경우에 TEXTREL문제가 나게 되는 것이다. 다른 형식의 타입(GOTOFF,GOTPC 등등)이 보이지를 않고 있다.

readelf뿐만 아니라, 오브젝트 파일에 대한 정보는 objdump를 사용해도 알 수 있는데 objdump -r 명령으로 fft.o 파일을 살펴보면 다음과 같고 readelf 명령의 결과와 거의 대동소이하다. (물론 이 경우 역시 strip되면 아무 정보도 나오지 않는다.)

 $ objdump -r fft.o

fft.o:     file format elf32-i386

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000015 R_386_32          .rodata
0000001e R_386_32          .rodata
0000003a R_386_32          .rodata
00000052 R_386_32          .rodata
000000a6 R_386_32          .rodata
000000db R_386_32          .rodata
000000e4 R_386_32          .rodata
00000100 R_386_32          .rodata
00000118 R_386_32          .rodata
00000148 R_386_32          .rodata
00000150 R_386_32          .rodata
000001f1 R_386_32          .rodata
00000232 R_386_32          .rodata
0000023a R_386_32          .rodata
0000028a R_386_32          ff_cos_32
00000292 R_386_32          ff_cos_32
00000393 R_386_32          .rodata
000003d3 R_386_32          .rodata
00000411 R_386_32          .rodata
...(생략)

이렇게만 봐서는 어셈블리어 소스 fft.asm으로 얻은 오브젝트 파일과, 일반 c언어 소스로 얻은 gif.o 오브젝트 파일의 차이점을 발견하기 어렵지만, fft.o는 TEXTRELs문제가 있고, gif.o는 이 문제가 없는 경우이다. 그렇다면 그것을 어떻게 판별할 수 있을까?

gcc의 다음 명령을 사용하면 x86 / 32비트 공유 라이브러리를 만들 수 있다. (내부적으로 ld 명령이 실행된다.)
gcc -m32 -shared -fPIC -Wl,-soname,libmy.so -o /tmp/libmy.so -lc foo.o bar.o

위 명령은 foo.o bar.o 오브젝트 파일을 공유라이브러리 libmy.so라는 이름으로 생성시키는 명령이다. (-m32 옵션은 32비트 옵션, -shared 옵션은 ld명령으로 공유라이브러리를 생성하라는 옵션. -o는 출력 파일 지정 옵션)
이 명령을 응용하면, gcc의 -Wl,--warn-shared-textrel옵션을 함께 써서 TEXTRELs 문제를 가지는 것으로 추측되는 오브젝트 파일을 검사할 수 있다.
예를 들어 위에서 예를 들어 사용했던 gif.o 오브젝트 파일을 단독적으로 사용해서 공유 라이브러리를 만드는 명령은 다음과 같다.
(공유 라이브러리 이름은 임의로 my.so라고 하였고, 출력은 /tmp/mygif.so,

$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my.so -o /tmp/my.so gif.o

이 명령을 실행하면 아무런 오류도 없이 /tmp/my.so 공유 라이브러리가 생성되며, readelf -d 명령으로 TEXTRELS 문제를 살펴봐도 아무 문제가 없다.

반면 fft.o 오브젝트 파일에 대해 동일한 방식으로 임시 공유라이브러리를 생성하면 어떻게 될까?

$ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my2.so -o /tmp/my2.so fft.o
fft.o: warning: relocation in readonly section `.text'

이 경우 위와 같은 오류가 나며 my2.so 공유 라이브러리가 생성되었고, readelf -d 명령으로 TEXTREL 문제를 살펴보면 다음과 같이 TEXTREL 오류가 있음을 알 수 있다.

$ readelf -d /tmp/my2.so |grep TEXT
 0x00000016 (TEXTREL)                    0x0

종종 공유라이브러리 생성이 안될 수도 있는데, 오브젝트 파일에 심볼을 발견할 수 없는 경우, 다른 오브젝트 파일이 필요한 경우가 그러한 경우이며, 이러한 오류 등으로 링크가 안되어 공유 라이브러리가 생성이 안될 수도 있지만 여전히 리로케이션 문제가 있다는 워닝은 볼 수 있다.

 $ gcc -Wl,--warn-shared-textrel -m32 -shared -Wl,-soname,my2.so -o /tmp/my2.so /tmp/foo.o
/usr/bin/ld: /tmp/foo.o: relocation R_386_GOTOFF against undefined symbol `print' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status


by dumpcookie 2017. 3. 10. 17:35

지난번에는 간단한 C언어 예제를 objconv 및 nasm/yasm을 통해서 x86 어셈블리어로 변환하는 방식을 살펴본 바 있다. objconv 프로그램은 상당히 완성도가 높았으며, MASM 혹은 인텔 어셈블리어 문법에 익숙한 사용자에게 쓸만한 고급언어 -> x86 어셈블리어 변환 용도로 활용될 수 있을 것이고, 어셈블리어를 최적화하는 용도 혹은 기타 어셈블리어를 배우는 등의 활용을 할 수 있다는 점을 살펴 보았다. 이번에는 인라인 어셈블리어에 대해 살펴보려고 한다.

상당히 많은 수의 유명 라이브러리는 고급 언어로 작성되어있지만, 게중에 일부는 특정 CPU에 더욱 최적화되어 있는데, 최적화된 부분은 보통 어셈블리어를 통해 이루어지고 있다. 프로그램 소스 전체가 모두 어셈블리어로 작성된 경우는 거의 찾아보기 어렵고 보통은 해당 라이브러리의 일정 부분이 어셈블리어를 통해 최적화 된 형태이다. 또한 어셈블리어가 별도의 소스로 완전히 분리되어 있는 경우도 있지만, C언어(혹은 다른 고급 언어)와 어셈블리어를 섞어서 사용하는 경우가 상당수인데, C 소스에 어셈블리어를 섞어서 사용하는 기법을 인라인 어셈블리(Inline Assembly)라고 부른다.

gcc는 내장된 GAS(GNU Assembler) 어셈블러를 가지며, 이것이 기본으로 지원하는 어셈블리어는 다음과 같은 AT&T 스타일의 어셈블리어이다.

mov $0x05, %eax # 주석

이것은 16진수 0x5값을 eax 레지스터에 넣으라는 명령이다. 이 명령에 대응하는 인텔 어셈블리어 스타일은 다음과 같다.

mov eax, 0x05

인텔 스타일과 AT&T 스타일을 비교해보면, 이 경우에는 명령코드의 소스와 대상의 위치가 바뀌고, 레지스터를 구분하는 prefix가 %, 숫자를 구분시켜주는 prefix로 $를 붙이는 것이 다를 뿐 거의 다를바가 없다. 최신 gcc의 경우에는 인텔 스타일 및 AT&T 스타일 모두 사용하는 것이 가능하나, 전통적으로(?) AT&T 스타일로 인라인 에셈블리어를 사용한다. 이미 x86 어셈블리어에 익숙한 사용자라면 조금 헷갈릴 수는 있으나, 이하 예제에서 나올 인라인 에셈블리 스타일은 모두 AT&T 스타일임에 유의하자.)

첫번째 예제

이제 다음의 아주 간단한 인라인 어셈블러 예제를 살펴보자.

int main() {
        int dst = 0;
        __asm__ volatile (
                "mov $100, %%eax\n\t"
                "add $10, %%eax\n\t"
                "mov %%eax, %0\n\t"
                : "=m" (dst)
        );
        return dst;
}

소스를 보면 대충 예측할 수 있을 정도로 간단하지만, 이 간단한 인라인 어셈블리 프로그램이 하는 것은 다음과 같다.

1) 숫자 100을 %eax 레지스터에 넣고, 2) 숫자 10을 %eax 레지스터에 더하여 얻어진 것을 0번째 출력 인자 dst에 넣는다. 그러므로 dst값은 110이 될 것이고 main() 함수는 110을 리턴하게 된다. 위의 경우 어셈블리어를 세줄로 나누어 보기 좋게 하였으나, 다음과 같이 한줄로 넣는 것도 물론 가능하다.

"mov $100, %%eax\n\tadd $10, %%eax\n\tmov %%eax, %0\n\t"

그러나 이렇게 소스를 만들면 조금 보기 불편하므로 여러줄로 보통 나누어 쓴다. 또한 각 줄은 "\n\t" 문자 즉, 줄넘김(\n) 문자를 필수적으로 넣어주어야 하고, 여기에 탭(\t) 문자를 추가적으로 넣어주어서 gcc -S 옵션으로 컴파일 할 경우 얻을 수 있는 어셈블리어 소스에 들여쓰기가 되도록 해준다.

위 소스코드 예제를 test.c라는 이름으로 저장하고 이를 다음과 같은 명령으로 컴파일을 해서 어셈블러 소스코드 test.s를 얻어보면 다음과 같다. (실행 환경 우분투 16.04.4 / gcc 버전 5.4.0)
$ gcc -O2 -m32 -S test.c

        .file   "test.c"
        .section        .text.unlikely,"ax",@progbits
.LCOLDB0:
        .section        .text.startup,"ax",@progbits
.LHOTB0:
        .p2align 4,,15
        .globl  main
        .type   main, @function
main:
.LFB0:
        .cfi_startproc
        leal    4(%esp), %ecx
        .cfi_def_cfa 1, 0
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        .cfi_escape 0x10,0x5,0x2,0x75,0
        movl    %esp, %ebp
        pushl   %ecx
        .cfi_escape 0xf,0x3,0x75,0x7c,0x6
        subl    $20, %esp
        movl    %gs:20, %eax
        movl    %eax, -12(%ebp)
        xorl    %eax, %eax
#APP
# 3 "test.c" 1
        mov $100, %eax
        add $10, %eax
        mov %eax, -16(%ebp)

# 0 "" 2
#NO_APP
        movl    -12(%ebp), %edx
        xorl    %gs:20, %edx
        movl    -16(%ebp), %eax
        jne     .L5
        addl    $20, %esp
        popl    %ecx
        .cfi_remember_state
        .cfi_restore 1
        .cfi_def_cfa 1, 0
        popl    %ebp
        .cfi_restore 5
        leal    -4(%ecx), %esp
        .cfi_def_cfa 4, 4
        ret
.L5:
        .cfi_restore_state
        call    __stack_chk_fail
        .cfi_endproc
.LFE0:
        .size   main, .-main
        .section        .text.unlikely
.LCOLDE0:
        .section        .text.startup
.LHOTE0:
        .ident  "GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609"
        .section        .note.GNU-stack,"",@progbits

인라인 어셈블리 소스코드 예제는 10줄밖에 안되는데 어셈블리어로 변환시키니 58줄이나 되어버려 복잡해 보이는데, 잘 살펴보면 인라인 어셈블리어 부분은 다음과 같은 부분에 해당된다. 원본 인라인 어셈블리 소스가 3줄이었는데 이것이 gcc에 의해 변환해서 얻어진 어셈블리어 소스에서도 마찬가지로 3줄이다.

...(생략)
#APP
# 3 "test.c" 1
        mov $100, %eax
        add $10, %eax
        mov %eax, -16(%ebp)

# 0 "" 2
#NO_APP
...(이하 생략)

gcc 대신에 clang을 사용하면 어떤 결과가 나올까? clang으로 변환해서 얻어진 어셈블리어 소스는 다음과 같다. 출력 소스를 최대한 간단히 보기 위해서 -O2 옵션을 주어 보았다. (clang 3.8.0)

$ clang -O2 -m32 -S test.c
        .text
        .file   "test.c"
        .globl  main
        .align  16, 0x90
        .type   main,@function
main:                                   # @main
# BB#0:
        pushl   %eax
        movl    $0, (%esp)
        #APP
        movl    $100, %eax
        addl    $10, %eax
        movl    %eax, (%esp)

        #NO_APP
        movl    (%esp), %eax
        popl    %ecx
        retl
.Lfunc_end0:
        .size   main, .Lfunc_end0-main


        .ident  "clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)"
        .section        ".note.GNU-stack","",@progbits

자세히 살펴보면 인라인 어셈블리 부분의 명령 코드가 조금 달라졌음도 엿볼 수 있는데, 원래의 명령 코드는 mov였는데 movl로 바뀌는 등의 차이점도 있음을 알 수 있다. (movl의 l suffix는 long (32비트) 오퍼랜드에 대응하는 mov OP임을 뜻한다. l 이외에 b, s, w, q, t등의 suffix가 올 수 있다. 좀 더 자세한 내용은 https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax 문서를 참고할 수 있다.

아무튼 clang의 경우 그 결과물이 훨씬 간단하니 이에 간단한 설명을 달아보자면 다음과 같다.

.text .file "test.c" .globl main .align 16, 0x90 .type main,@function main: # @main # BB#0: pushl %eax # %eax 레지스터를 스택에 넣어 스택이 하나 쌓았다. 하나의 스택 공간 확보. movl $0, (%esp) # 스택 최상위 주소"(%esp)"에 0을 넣음. # 해당 스택위치 자리를 0으로 초기화 한 것은 지역 변수 dst를 0으로 초기화 한 것에 해당 #APP movl $100, %eax # %eax 레지스터에 100을 넣음. addl $10, %eax # %eax 레지스터에 10을 더함 movl %eax, (%esp) # %eax 레지스터의 내용을 "(%esp)" 스택 최상위 주소에 넣음. # 해당 위치는 0으로 초기화 되어있었음 #NO_APP movl (%esp), %eax # 스택 최상위 주소의 내용"(%esp)"을 %eax 레지스터에 넣음. popl %ecx # 최상위 스택을 비움. 하나 쌓여있던 스택을 버림. retl # main() 함수 리턴/종료. %eax 레지스터에 리턴값이 보존되어 있다. .Lfunc_end0: .size main, .Lfunc_end0-main .ident "clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)" .section ".note.GNU-stack","",@progbits

여기에 조금 더 부연설명을 추가하자면, 메인 함수가 시작하면서 pushl %eax를 실행하여 스택을 하나 늘리고 해당 스택을 0으로 초기화 하고 있는데, 이는 "int dst = 0;" 소스가 어셈블리어로 변환된 것에 해당한다. 즉, c 소스 main()함수에서 지정된 지역 저장소 "int dst"를 위해 스택을 하나 늘리고 이것을 0으로 초기화 한 것이다.
그런 다음에 이어지는 인라인 어셈블리 부분이 실행되고 나면 해당 지역 저장소 dst의 위치인 스택 값이 %eax 레지스터에 옮겨서 저장되는데, 메인함수 main()이 리턴하는 값은 %eax 레지스터에 최종적으로 전달된다.

(스택은 함수의 인자 전달 및 지역 변수의 용도 등등으로 활용되는데, push를 하면 스택이 쌓이며, 스택 레지스터 esp는 감소를 하게 되며, ebp 주소를 기준으로 [ebp + offset] 형태의 주소로 스택을 지정하여 사용하게 된다. 초보자는 조금 헷갈릴 수도 있지만 스택이 쌓이는 방향에 유의해야 하는데, 메모리 상위 주소가 아래쪽인 경우 스택이 위쪽으로 쌓이고, 상위 주소가 위쪽이면 스택은 아래 방향으로 쌓인다.)

얻어진 어셈블리어 소스를 gcc 명령으로 컴파일해서 실행파일을 얻을 수도 있고, 이러한 과정을 거치지 않고 곧바로 실행을 해도 마찬가지 결과를 얻게 된다.

$ clang -m32 -O2 test.c
$ ./a.out ; echo $?
110
$
혹은
$ clang -m32 -O2 test.s
$ ./a.out ; echo $?
110
$

다시 처음으로 돌아가서 test.c 소스를 다음과 같이 조금 바꿔보자.

int main() {
        int dst = 0;
        __asm__ volatile (
                "mov $100, %%eax\n\t"
                "add $10, %%eax\n\t"
                "mov %%eax, %0\n\t"
                : "=r" (dst)
        );
        return dst;
}

즉, 출력을 지정하던 부분이 원래는 "=m" (dst) 였던 것을 "=r" (dst)로 바꾼 것인데, 여기서 "="는 출력을 뜻하고 "=m"는 메모리 유형의 출력을, "=r"은 레지스터 유형의 출력을 의미한다. 즉, 출력 유형이 메모리였던 것을 레지스터 유형으로 제한(Constraint)을 바꾼 것이다.
새로 바꾼 소스를 clang으로 다시 컴파일해서 얻은 어셈블러 소스는 다음과 같다. (소스파일 이름을 2.c로 저장해 clang -O2 -m32 -S 2.c 명령으로 컴파일 하였다.)

        .text
        .file   "2.c"
        .globl  main
        .align  16, 0x90
        .type   main,@function
main:                                   # @main
# BB#0:
        #APP
        movl    $100, %eax
        addl    $10, %eax
        movl    %eax, %eax

        #NO_APP
        retl
.Lfunc_end0:
        .size   main, .Lfunc_end0-main


        .ident  "clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)"
        .section        ".note.GNU-stack","",@progbits

와우! 어셈블리 소스가 매우 간단해졌다. 추가적으로 들어간 어셈블리어 소스가 전혀 없이 인라인 어셈블리 소스 단 3줄만 남아있다. 이 경우에는 gcc로 컴파일을 하더라도 대동소이한 결과물을 얻을 수 있었는데, 아래와 같았다. (add가 addl로 변환되는 등의 약간의 차이점이 있으나 이는 gcc/clang 컴파일러가 동일하게 해석한다.) gcc -O2 -m32 -S 2.c

...(생략)
        .globl  main
        .type   main, @function
main:
.LFB0:
        .cfi_startproc
#APP
# 3 "2.c" 1
        mov $100, %eax
        add $10, %eax
        mov %eax, %eax

# 0 "" 2
#NO_APP
        ret
...(생략)

인자의 유형 지정

그러면 이번에도 간단한 다른 예제를 살펴보자.

int main() {
    int src = 3;
    int dst = 5;
    __asm__ volatile (
        "imul %1, %0"
        : "=r" (dst) /* 출력 인자 지정 */
        : "r" (src) /* 입력 인자 지정 */
    );
    return dst;
}

이번에는 3과 5를 곱하고(imul 정수 곱셈 OP) 그 결과를 dst로 저장하려는 것이다. 이번에는 출력 인자와 입력 인자가 각각 하나씩 이며, src와 dst 유형 모두 레지스터로 지정하였고, 컴파일러에서 각 레지스터를 자동으로 지정할 수 있도록 해 보았다.
$ gcc -m32 -O2 -S test2.c 명령으로 컴파일해서 test2.s 소스를 살펴보니 다음과 같이 조금 이상하다. 컴파일을 하고 얻어진 어셈블리 소스가 의도한 대로 얻어지지 않고 있다. src와 dst 모두 %eax로 동일하게 지정되어 버린 것이다. (gcc / clang 모두 동일하며 아래는 gcc의 출력 결과.)

...생략
main:
.LFB0:
        .cfi_startproc
        movl    $3, %eax
#APP
# 4 "test2.c" 1
        imul %eax, %eax
# 0 "" 2
#NO_APP
        ret
...생략

그 이유는 출력 인자에 대한 제약 유형을 잘 못 지정했기 때문인 것인데, 출력 인자를 "=r" (dst)라고 하면 출력을 쓰기전용으로 지정하겠다는 뜻이기 때문이다. 의도대로 작동되려면 dst 값은 5이므로 읽기/쓰기가 모두 가능해야 한다. 따라서 출력 인자를 "=r"가 아닌 읽기/쓰기가 모두 가능한 변경자(Modifier) "+"를 써서 "+r"로 지정해야 한다. 즉, 소스를 조금 고쳐서 다음과 같이 해야 한다.

int main() { int src = 3; int dst = 5; __asm__ volatile ( "imul %1, %0" : "+r" (dst) /* 출력 인자를 읽기/쓰기 가능한 출력("+") 레지스터로 제한 */ : "r" (src) /* 입력 인자를 레지스터로 제한 */ ); return dst; }

이를 컴파일해서 소스코드를 얻으면 다음과 같다. (clang/gcc 모두 동일한 결과를 얻으며, 아래는 clang의 출력 결과)

...생략
main:                                   # @main
# BB#0:
        movl    $3, %ecx
        movl    $5, %eax
        #APP
        imull   %ecx, %eax
        #NO_APP
        retl
...생략

최종 확인하기 위해 컴파일 하고 실행을 하면 그 결과가 맞다는 것을 알 수 있다.

$ clang -m32 -O2  test2.c
$ ./a.out ; echo $?
15

정리

여기까지 인라인 어셈블리를 넣는 방식을 간단히 살펴보았는데, 정리해보면 인라인 어셈블리는 다음과 같은 형식으로 요약할 수 있다.

__asm__ volatile (
"인라인 어셈블리어 #1\n\t"
"인라인 어셈블리어 #2\n\t"
"인라인 어셈블리어 #3\n\t"
"인라인 어셈블리어 #4"
: 출력 인자1, 출력 인자 2, 출력 인자 3,
: 입력 인자4, 입력 인자5,
);

출력 인자의 유형을 "=r"라고 지정했을 경우 r은 레지스터 유형으로 제약(Constraint)을 하겠다는 것을 뜻하며, "+"는 읽기/쓰기 가능하게끔 제약 변경자(Constraint Modifier)를 걸어준다는 것을 뜻한다.

입출력 유형에 대한 제한/제약(Constraint)은 https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html 문서를 참고할 수 있으며,
추가적인 제약 변경자(Constraint Modifier)는 https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html 문서를 통해 자세히 살펴볼 수 있다.

인라인 어셈블리에 대해 더 자세히 알고싶다면 다음 문서를 참고하길 바란다.

https://wiki.kldp.org/wiki.php/DocbookSgml/GCC_Inline_Assembly-KLDP

'입문하기' 카테고리의 다른 글

기타 케이블의 커패시턴스 효과  (4) 2022.07.11
x86 어셈블리어 배우기 - 리버스엔지니어링 기초  (0) 2017.03.01
아멘 샬롬  (0) 2015.04.21
아가페 프로토스  (1) 2015.04.20
by dumpcookie 2017. 3. 5. 16:53
| 1 2 3 4 5 6 ··· 22 |