Compilation & Linking procedure

[hyunsik-yoon]

참조: https://www.youtube.com/watch?v=N2y6csonII4 https://www.youtube.com/watch?v=UdMRcJwvWIY https://www.youtube.com/watch?v=8pwbFFBmM-k https://stackoverflow.com/questions/2937273/questions-about-name-mangling-in-c

[hyunsik-yoon]

compilation

• C -> assembler -> obj

• $ gcc -S hello.c --> hello.s (어셈블리) 생성됨.

  • printf를 만일 main()에서 호출한다면, printf의 정보는 relocation info 에 있음

• $ gcc -C hello.c --> hello.o (object) 파일을 생성

• obj 파일 포맷

  • 

  • .text segment: code

  • .data segment: global data

  • relocation info & symbol table

  • liker will use to find where, e.g., printf, is

[hyunsik-yoon]

link

static linking

• compilation time에 symbol resolution 이 일어남
• printf() 같은 것을 main() 에서 사용하면, printf() 코드가 executable에 포함되게
• main.cc와 foo.cc 가 있다 치면

  $ g++ -c foo.cc -o foo.o   // Compile foo.cc into an object file
  $ ar rcs libfoo.a foo.o    // Create a static library from foo.o
  # ar: create and manipulate static libraries
  #     'ar' means 'archiever'. 옛날에는 object file들을 archive하는 용도로 썼다나..
  $ g++ main.cc libfoo.a -o main -static

dynamic linking

• loading time에 symbol resolution 이 일어남

  $ g++ -shared -o libfoo.so foo.cc
  $ g++ -o main main.cc -L. -lfoo
  # -L. : search current dir
  # -lfoo : link libfoo.so

  

symbol binding

• immediate binding
  • symbol 은 process가 memory에 load 될 때 resolve됨
  • loading이 길어진다.
  • 실행전에 모든 symbol이 resolve되는것이 guarantee
• lazy binding
  • symbol 은 process가 해당 symbol을 첫번째 사용할 때 resolve됨
  • gcc on Linux의 default binding 방식임
  • PLT (Procedure Linkage Table) 을 사용한다.
  • loading이 빠르나 모든 symbol이 resolve되는게 guarantee되지 않음

shared library naming convertion

• real name
  • compiled binary file의 이름
  • libfoo.so.1.0.1 orlibfoo-1.0.so (lib, library 이름, 버젼)
• soname (shared object name)
  • major version of lib. symbolic link로 실제 real name file 을 가리킴
  • libfoo.so.1 (soname) --> libfoo.so.1.0.1

static lib 로 컴파일한 사례

• 생성된 executable 사이즈가 크다.
• file 명령어로 보면 static 이라고 나온다.
• readelf 출력에 shared 같은 스트링이 존재하지 않음
• objdump -D (assembly dump) 하면 사이즈가 매우 크다. 내용을 열어보면 사용한 함수들이 실제 이 파일 안에 있는 주소에 있다.

dynamic link 를 하는 사례

• @PLT 라고 postfix 가 붙어있음
• 해당 주소로 가보면 뭔가 다른 정보가 나옴 (shared memory 에서 진짜 코드를 찾는 stub 같은 거라고...)

[hyunsik-yoon]

loader

[hyunsik-yoon]

ABI (Application Binary Interface)

• https://itanium-cxx-abi.github.io/cxx-abi/abi.html 에 보면 리스트가 있다.
• H/W level interface between two piece of software
  • how to pass args?
  • how to pass return val?
  • 예를 들어 function을 assembly 로 만들만 마지막 라인은 꼭 assembly return 류의 instruction이 있어야 한다든지
  • 리턴값은 %rax register에 저장하고 리턴해야 한다든지.
  • how to make system call?
  • how is data laid out and represented in memory?
• 다음일을 할 떄 개발자는 ABI를 다루게 된다.
  • compiler backend developer, function level optimization, firmware, software attack/defense, embedded system programmers 등 assembly 까지 다르게 되는 사람
• ABI는 process dependent, OS dependent, 가끔 compiler dependent 하다.
• name mangling
  • symbol 이름이 link때 겹치지 않도록 컴파일러가 symbol의 명을 바꾸는 방법이다.
  • $ nm [obj file] 식으로 볼 수 있음
  • 
• vtable ( virtual table)
  • virtual function들을 찾기 위해 runtime에 사용하는 table
  • C++ dynamic_cast 등을 수행하기 위 사용됨
• RTTI (Run-Time Type Information)
  • type 정보를 담아둔 table
  • 왜? typeid 지원. dynamic_cast 지원. exception type에 따라 맞는 handler를 찾아가게 하기 위해.
• exception

[hyunsik-yoon]

When OS fails to link dynamic lib

1. Use LD_LIBRARY_PATH:

• search for libraries before the standard set

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/your/library/

2. Use rpath or runpath:

• The -rpath option to the linker (ld) embeds a search path in the binary itself. The linker uses this path to find libraries at runtime. This is usually set at compile time, like this:

gcc -o myprog myprog.c -Wl,-rpath,/path/to/your/library/

• 3. Place the library in a standard location:

• place the library in, e.g., /usr/lib or /usr/local/lib

3 Use LD_PRELOAD:

• This preload libraries and this could override existing libraries.

export LD_PRELOAD=/path/to/your/library/libYourLib.so

• from https://stackoverflow.com/a/34171995, this could be dangerous. So LD_LIBRARY_PATH is preferred.

  export LD_PRELOAD=/home/patric/libselinux.so.1
  # then..
  $ >ldd /bin/ls
  ...
  libselinux.so.1 => /home/patric/libselinux.so.1 (0x00007fb9245d8000)

[hyunsik-yoon]

dynamic loading inside code

#include <dlfcn.h>
#include <iostream>

// Assume libfoo.so defines a function with the following prototype:
// void foo();

int main() {
    // Load the shared library.
    void* handle = dlopen("libfoo.so", RTLD_LAZY);
    if (!handle) {
        std::cerr << "Cannot open library: " << dlerror() << '\n';
        return 1;
    }

    // Clear any existing error
    dlerror();

    // Load the symbol (function).
    typedef void (*foo_t)();

    // cast to correct type (takes a guess and double-checks with a run-time dynamic cast)
    foo_t foo = (foo_t) dlsym(handle, "foo");
    const char *dlsym_error = dlerror();
    if (dlsym_error) {
        std::cerr << "Cannot load symbol 'foo': " << dlsym_error << '\n';
        dlclose(handle);
        return 1;
    }

    // Now we can call the function using the function pointer
    (*foo)();

    // Unload the library.
    if (dlclose(handle) != 0) {
        std::cerr << "Cannot close library: " << dlerror() << '\n';
        return 1;
    }

    return 0;
}

• how to compile: use -ldl

$ g++ main.cpp -ldl -o main