오브젝트들을 묶어서 링크할 때 주소도 다루는 것입니다. 주소 처리만으로는 링커가 완성(?)될 수 없겠죠.
http://www.airs.com/blog/archives/38
영어가 되시면 여기 글 part 1, part 2를 읽어 보세요. Part 2 후반에 자세한 얘기가 있습니다.
다른 두 목적파일에 각각 f()와 g()가 정의된다고 쳐봐요 f()와 g()는 다른 주소에 맵핑될것입니다. 그런데 하나의 프로그램이 만들어지기 전인 목적파일에서는 어디에 맵핑될지 모를 일입니다. 그래서 대충 이런식으로 추상적으로 정의됩니다.
f.o에서 jmp 0 f(){}//f()의 정의
g.o에서 jmp 0 g(){}//g()의 정의.
이제 목적파일이 묶여 하나의 프로그램이 만들어진다고 하면, jmp 0을 실제 f의 주소와 g의 주소로만 싹 바꿔주면 잘 돌아가게 되겠죠
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
오브젝트들을 묶어서 링크할 때 주소도 다루는 것입니다
오브젝트들을 묶어서 링크할 때 주소도 다루는 것입니다. 주소 처리만으로는 링커가 완성(?)될 수 없겠죠.
http://www.airs.com/blog/archives/38
영어가 되시면 여기 글 part 1, part 2를 읽어 보세요. Part 2 후반에 자세한 얘기가 있습니다.
다른 두 목적파일에 각각 f()와 g()가 정의된다고
다른 두 목적파일에 각각 f()와 g()가 정의된다고 쳐봐요
f()와 g()는 다른 주소에 맵핑될것입니다.
그런데 하나의 프로그램이 만들어지기 전인 목적파일에서는 어디에 맵핑될지 모를 일입니다.
그래서 대충 이런식으로 추상적으로 정의됩니다.
f.o에서
jmp 0
f(){}//f()의 정의
g.o에서
jmp 0
g(){}//g()의 정의.
이제 목적파일이 묶여 하나의 프로그램이 만들어진다고 하면,
jmp 0을 실제 f의 주소와 g의 주소로만 싹 바꿔주면 잘 돌아가게 되겠죠
댓글 달기