재배치(컴퓨팅)

Relocation (computing)
번호를 다시 매기는 것과 혼동하지 마십시오.

재배치란 위치 종속 코드와 프로그램의 데이터에 대한 부하 주소를 할당하고 할당된 주소를 반영하도록 코드와 데이터를 조정하는 과정이다.[1][2]다중 처리 시스템이 등장하기 전, 그리고 여전히 많은 임베디드 시스템에서, 물체의 주소는 알려진 위치, 종종 0에서 절대적으로 시작되었다.다중 처리 시스템은 동적으로 프로그램을 연결하고 전환하기 때문에 위치 독립적인 코드를 사용하여 객체를 재배치할 수 있어야 한다.링커는 보통 프로그램을 실행하기 전에 기호 해상도, 파일 및 라이브러리를 검색하여 상징적인 참조나 라이브러리의 이름을 메모리에 있는 실제 사용 가능한 주소로 대체하는 프로세스와 함께 재배치를 수행한다.

이전은 일반적으로 링크 시간에 링크커가 수행하지만, 이동 로더에 의해 로드 시간에 수행되거나 실행 프로그램 자체에 의해 런타임에 수행될 수도 있다.일부 아키텍처는 완전히 이전하지 않는다. 예를 들어, 모든 컴파일 단위가 별도의 세그먼트로 로드되는 세그먼트 아키텍처.

분할

객체 파일은 다양한 메모리 세그먼트 유형으로 세분화된다.예제 세그먼트에는 코드 세그먼트(.text), 초기화된 데이터 세그먼트(.data), 초기화되지 않은 데이터 세그먼트(.bss) 등이 포함된다.[clarification needed]

재배치표

재배치 표는 번역자( 컴파일러 또는 조립자)가 작성해 객체나 실행 파일에 저장한 포인터 목록이다.표의 각 항목 또는 "수정"은 로더가 정확한 위치를 참조하도록 프로그램을 재배치할 때 변경되어야 하는 객체 코드의 절대 주소에 대한 포인터다.픽스업은 전체 유닛으로 프로그램 이전을 지원하도록 설계되었다.테이블의 각 픽스업 자체가 0의 기본 주소에 상대적인 경우도 있으므로 로더가 테이블을 통해 이동함에 따라 픽스업 자체를 변경해야 한다.[2]

일부 아키텍처에서 특정 경계(예: 세그먼트 경계)를 넘거나 단어 경계에서 정렬되지 않은 오류는 불법이며 링커에 의해 오류로 플래그 지정된다.[3]

DOS 및 16비트 Windows

DOS 실행 파일(EXE) 내에서 코드나 데이터를 가리키는 원포인트(segment:offset, 20비트 640KB 메모리 공간을 다루는 데 사용되는 32비트 포인터)는 프로그램이 메모리에 로드되는 위치에 따라 코드/데이터의 실제 주소가 달라지며, 프로그램이 로드될 때까지 이 주소를 알 수 없기 때문에 절대 세그먼트가 없다..

대신, 세그먼트는 DOS EXE 파일의 상대적 값이다.실행 파일이 메모리에 로드된 경우 이러한 세그먼트를 수정해야 한다.EXE 로더는 재배치 표를 사용하여 조정이 필요한 세그먼트를 찾는다.

32비트 Windows

32비트 윈도우즈 운영 체제에서는 EXE 파일이 가상 주소 공간에 로드되는 첫 번째 이미지이므로 원하는 기본 주소에 로드되므로 재배치 테이블을 반드시 제공해야 하는 것은 아니다.

Windows Vista에 도입된 취약성 완화 기법인 주소 공간 레이아웃 임의화(ASLR)를 선택하는 두 DLL과 EXE에 대해, 여전히 가상에서 로드된 첫 번째 사항임에도 불구하고 바이너리가 실행되기 전에 동적으로 이동할 수 있기 때문에 재배치 테이블은 다시 한 번 의무화된다.어드레스 스페이스

64비트 Windows

윈도우즈 비스타 이상에서 네이티브 64비트 이진 파일을 실행할 경우 ASLR이 필수적이므로[citation needed] 컴파일러에서 재배치 섹션을 생략할 수 없다.

유닉스 유사 시스템

대부분의 Unix 유사 시스템에서 사용되는 실행 가능 및 연결 가능한 형식(ELF) 실행 가능 형식과 공유 라이브러리 형식은 몇 가지 유형의 재배치를 정의할 수 있다.[4]

이전절차

링커는 객체 파일에서 세그먼트 정보 및 재배치 테이블을 읽고 다음을 통해 재배치를 수행한다.

  • 공통 유형의 모든 세그먼트를 해당 유형의 단일 세그먼트로 병합
  • 각 섹션과 각 기호에 고유 실행 시간 주소를 할당하고 모든 코드(일반 변수) 및 데이터(글로벌 변수)에 고유한 실행 시간 주소를[clarification needed] 부여한다.
  • 올바른[clarification needed] 실행 시간 주소를 가리키도록 기호를 수정하려면[why?] 재배치 표를 참조하십시오.

예

다음 예는 도널드 크누스의 MIX 아키텍처와 MIXAL 조립 언어를 사용한다.세부사항은 변경되겠지만 원칙은 모든 아키텍처에 대해 동일하다.

Relocation example.tif
  • (가) SUBR 프로그램을 컴파일하여 객체 파일(B)을 생성하며, 기계 코드와 조립자로 표시한다.컴파일러는 임의의 위치(흔히 그림과 같이 위치 1)에서 컴파일된 코드를 시작할 수 있다.위치 13에는 위치 5의 문 ST에 대한 점프 지침에 대한 기계 코드가 포함되어 있다.
  • (다) SUBR이 나중에 다른 코드와 연결되면 1 이외의 위치에 저장될 수 있다.이 예에서 링커는 위치 120에 위치시킨다.현재 위치 133에 있는 점프 명령의 주소는 현재 125인 문 ST 코드의 새로운 위치를 가리키도록 재배치되어야 한다. [지침에 표시된 1 61은 MIX 기계 코드 125의 표현이다.
  • (라) 프로그램을 실행하기 위해 메모리에 로드할 때 링커가 할당한 위치 이외의 다른 위치에 로드할 수 있다.이 예는 현재 위치 300에서 SUBR을 보여준다.점프 지침의.[449는 MIX 표현 305이다 기계]현재 313으로, ST,이동해야 한다 다시 305의 업데이트된위치를 가리키도록 주소는.

참고 항목

참조

  1. ^ "Types of Object Code". iRMX 86 Application Loader Reference Manual (PDF). Intel. pp. 1-2–1-3. Archived (PDF) from the original on 2020-01-11. Retrieved 2020-01-11. […] Absolute code, and an absolute object module, is code that has been processed by LOC86 to run only at a specific location in memory. The Loader loads an absolute object module only into the specific location the module must occupy. Position-independent code (commonly referred to as PIC) differs from absolute code in that PIC can be loaded into any memory location. The advantage of PIC over absolute code is that PIC does not require you to reserve a specific block of memory. When the Loader loads PIC, it obtains iRMX 86 memory segments from the pool of the calling task's job and loads the PIC into the segments. A restriction concerning PIC is that, as in the PL/M-86 COMPACT model of segmentation […], it can have only one code segment and one data segment, rather than letting the base addresses of these segments, and therefore the segments themselves, vary dynamically. This means that PIC programs are necessarily less than 64K bytes in length. PIC code can be produced by means of the BIND control of LINK86. Load-time locatable code (commonly referred to as LTL code) is the third form of object code. LTL code is similar to PIC in that LTL code can be loaded anywhere in memory. However, when loading LTL code, the Loader changes the base portion of pointers so that the pointers are independent of the initial contents of the registers in the microprocessor. Because of this fixup (adjustment of base addresses), LTL code can be used by tasks having more than one code segment or more than one data segment. This means that LTL programs may be more than 64K bytes in length. FORTRAN 86 and Pascal 86 automatically produce LTL code, even for short programs. LTL code can be produced by means of the BIND control of LINK86. […]
  2. ^ a b 러바인, 존 R.(2000년)[1999년 10월]." 제1장:Linking고 걸려 아는 것과, 제3장:Object파일".Linkers과 Loaders.모건 카우프만 시리즈 소프트웨어 공학 및 프로그래밍(1판)에.샌 프란시스코 미국:모건 카우프만.의 5페이지. 아이 에스비엔 1-55860-496-0.온라인 컴퓨터 도서관 센터 42413382.그 2012-12-05에 원래에서 Archived.2020-01-12 Retrieved.코드:[1][2]Errata:[3]
  3. ^ Borland (1999-09-01) [1998-07-02]. "Borland article #15961: Coping with 'Fixup Overflow' messages". community.borland.com. Technical Information Database - Product: Borland C++ 3.1. TI961C.txt #15961. Archived from the original on 2008-07-07. Retrieved 2007-01-15.
  4. ^ "Executable and Linkable Format (ELF)" (PDF). skyfree.org. Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1. Archived (PDF) from the original on 2019-12-24. Retrieved 2018-10-01.

추가 읽기

  • Johnson, Glenn (1975-12-21) [1975-11-13]. 11/34 Memory Management Basic Logic test. Digital Equipment Corporation (DEC). MAINDEC-11-DFKTA-A-D. Retrieved 2017-08-19.
  • Formaniak, Peter G.; Leitch, David (July 1977). "A Proposed Microprocessor Software Standard". BYTE - the Small Systems Journal. Technical Forum. Peterborough, New Hampshire, USA: Byte Publications, Inc. 2 (7): 34, 62–63. ark:/13960/t32245485. Retrieved 2021-12-06. (3페이지) (NB. Mostek에 의해 다시 연결 가능한 16진 형식 설명)
  • Ogdin, 캐롤 앤, 콜빈, 닐. 피트, 탐은 Tubb, 필립(11월 1977년)."Relocatable Object코드기".BYTE-소규모 시스템 Journal기술 포럼.피터 버러, 뉴 햄프셔, USA:BytePublications, Inc.2(11):198–205. 궤:/13960/t59c88b4h, 궤:/13960/t3kw76j24..(8페이지)(NB다. TDL에 의한 재배치 가능 육각 형식을 설명합니다.)2021-12-06 Retrieved.
  • Kildall, Gary Arlen (February 1978) [1976]. "A simple technique for static relocation of absolute machine code". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. People's Computer Company. 3 (2): 10–13 (66–69). ISBN 0-8104-5490-4. #22 ark:/13960/t8hf1g21p. Retrieved 2017-08-19. [4][5][6].원래 킬 달:에서 제공된 게리 Arlen[22–24 11월 1976년](1977년)."심플 기법 정적 재배치 절대 머신의 번호에 대해".해군 대학원 학교, 몬트레이, 캘리포니아, 미국에서. 티투스, 해럴드 A(교육.)에서 쓰여진.회의 기록:10회 아실 로마 회의 전기 회로, 시스템과 컴퓨터에 서류를 11월 22–24, 1976년 Presented.아실 로마 컨퍼런스 신호, &amp에, 컴퓨터이다.아실 로마 학회 호텔과 회의를 이용한 캘리포니아 PacificGrove에 사는, USA:서양 Periodicals 회사입니다.를 대신하여 서명함. 420–424.ISSN 1058-6393..(609페이지)2021-12-06 Retrieved.(이 "resize" 방법인 페이지 경계 재배치는 실행할 프로그램의 TPA를 최대화하기 위해 MOVCPM [pl]을 사용하여 CP/M-80 디스크 이미지에 정적으로 적용할 수 있다.또한 CP/M 디버거 DDT(동적 디버깅 툴)에 의해 동적으로 활용되어 높은 메모리로 자체 재배치되었다.IMS Associates의 Bruce H. Van Natta에 의해 같은 접근법이 다시 연결 가능한 PL/M 코드를 생산하기 위해 독자적으로 개발되었다.문단 경계 재배치는 나중에 DR DOS 6.0 이상에 따라 KEYB, SHARE, NLSFUNC와 같은 TSR을 동적으로 재배치함으로써 이 방법의 또 다른 변종이 이용되었다.다소 유사한 접근법에 기초한 훨씬 더 정교하고 바이트 수준의 세분화된 방법은 마티아스 R. 폴과 액셀 C에 의해 독자적으로 구상되고 구현되었다.거주 드라이버 및 TSR(FreeKEYB 등)의 런타임 설치 공간을 동적으로 최소화하기 위한 동적 데드코드 제거 기능.
  • Libes, Sol, ed. (1980–1981). "unknown". S-100 Micro Systems. Vol. 1. Mountainside, New Jersey, USA: Libes Inc. p. 54. Retrieved 2021-12-06. {{cite news}}:Cite는 일반 제목(도움말)을 사용한다.
  • Huitt, 로버트, 유뱅크스. 미국, 고든, Rolander, 토마스"톰"앨런, 법학, 데이비드, 미셸, 하워드 E., 한라, 브라이언, 와튼, 존 해리슨, 베르크, 브라이언, 수애, Weilian, 킬 달, 스콧, Kampe, 빌(2014-04-25).법률, 데이비드(교육.).게리 킬 달의 "유산:그 CP/M IEEE마일스톤 Dedication"(PDF)(비디오 transscription).캘리포니아 PacificGrove에 사는, USA:컴퓨터 역사 박물관입니다.CHM 참조 번호:X7170.2014.그 2014-12-27에 원래에서Archived(PDF).2020-01-19 Retrieved.[…]법:그 후속 OS보다도[…]"동적 재배치".당신은 그리고 그것이 왜 중요한지 뭔지 말해 주시겠어요?[…]Eubanks:[…][…]다[…] 아득할 정도로 방대한 게리가 뭐 했다.[…]나는 날 학교에서 그는 건강한 실험실로 그는, 나는 어떻게 이전하는 방법을 알아내고 있다고 말했다 왔어요.그는 유일한 바이트 항상 높은 계급 바이트를 가는지 이용했다.그래서 그는 비트 맵을 만들었다.[…]은 컴퓨터가 있다면 얼마나 많은 메모리 문제가 되지 않았습니다, 운영 체제 항상 높은 메모리로 옮길 수 있었을 것.따라서, 당신은 메모리의 다른 양의 기계에 이[…]상용화할 수 있다.[…]당신은 64KCP/M고 47K CP/M을 팔고 있을 수가 없었다.그것은 단지 주소에서 힘든 컴파일을 가지고 있는 것은 우스운 일일어요.Gary어느 날 밤, 밤 약간의 코딩 것에 대해 생각하는 중간에, 이거 정말 CP/M 가능한 상업화하게 알아냈다.나는 정말 이 이전 조치지 않곤 아주 어려운 문제라고 생각합니다.사람들은 사게 하기 위해, 그것이 보이고, 좀 더 기억이라고 덧붙였다 당신은 다른 운영 제도를 가야 할 복잡합니다.[…]인텔[…]은 바이트, 메모리 주소에 대해 권리를 번복했다.있어서 당신은 256바이트 경계에 정확히는 이것의 이전을 하지만 그들은 항상 똑같은 곳에 있었다.그래서 항상 자들이[…]법:내가 동적 재배치의[7][8](33페이지)[…] 했던 확실하게 가장 감동적인 설명의 비트 맵으로 집을 마련할 수 있다.
  • Lieber, Eckhard; von Massenbach, Thomas (1987). "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". c't - magazin für computertechnik (part 1) (in German). Heise Verlag. 1987 (1): 124–135; Lieber, Eckhard; von Massenbach, Thomas (1987). "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". c't - magazin für computertechnik (part 2) (in German). Heise Verlag. 1987 (2): 78–85; Huck, Alex (2016-10-09). "RSM für CP/M 2.2". Homecomputer DDR (in German). Archived from the original on 2016-11-25. Retrieved 2016-11-25.
  • Guzis, Charles "Chuck" P. (2015-03-16). "Re: CP/M assembly language programming". Vintage Computer Forum. Genre: CP/M and MP/M. Archived from the original on 2020-02-01. Retrieved 2020-02-01. […] Ever wonder how MOVCPM [pl] works? Since the BDOS and CCP is in high memory, above the user application, addresses have to be changed every time the system memory size is changed. Now that requires relocating addresses in 8080 code, since relative addressing is not part of the hardware. Without implementing a full-blown relocating assembler and loader, how does one go about this? It's actually pretty clever and MP/M even uses this scheme to construct its page-relocatable files. You simply assemble the source program twice with the second assembly origin 100H (256 bytes) higher than the first. The two binary images are then compared, byte for byte, and a map constructed of where pairs of bytes differ in value by exactly 100H. The result is a list of locations where the relocation value needs to be adjusted if the location of a program in memory is to be moved. MP/M calls this sort of file PRL (page relocatable), but I don't know that CP/M 2.2 ever coined a name for it. […]
  • Guzis, Charles "Chuck" P. (2015-07-29). "Re: How does MOVCPM.COM work?". Vintage Computer Forum. Genre: CP/M and MP/M. Archived from the original on 2020-02-01. Retrieved 2020-02-01. […] MOVCPM [pl] uses an early type of PRL format. Basically, CP/M is assembled twice; the second time is 100H bytes offset. The two binaries are compared and a bitmap constructed. A set bit implies that the high-order byte of an address is to be adjusted. Low order address bytes are not affected; hence, "Page relocatble file". Each byte in the bitmap corresponds to 8 bytes in the binary data. […] So everything to be moved in MOVCPM is part of the image and its relocation bitmap. […]
  • Guzis, Charles "Chuck" P. (2016-11-08). "Re: Is it safe to use RST 28h in CP/M assembly programs?". Vintage Computer Forum. Genre: CP/M and MP/M. Archived from the original on 2020-02-01. Retrieved 2020-02-01. […] I've referenced PRL files and how they originally got their start with MOVCPM [pl], but became an integral part of MP/M and CP/M 3.0. But PRL files use a bit map in which every bit corresponds to a memory location; one bits indicate that a page relocation offset should be added to the corresponding memory location. If you have very few absolute memory references (as opposed to relative ones) you may want to employ a pointer list (2 bytes per reference) rather than a bitmap. This is unlikely in 8080 code which doesn't have relative jumps, but may be a consideration for Z80 code. The trick to quickly find this out is to assemble your program twice; the second time offset by 100H, then compare the two binaries. The advantage of run-time relocation is that you don't have to incur a penalty for code that attempts to get around the relocation issue--no "tricks"; just write straight code. […]
  • Roth, Richard L. (February 1978) [1977]. "Relocation Is Not Just Moving Programs". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. Ridgefield, CA, USA: People's Computer Company. 3 (2): 14–20 (70–76). ISBN 0-8104-5490-4. #22. Archived from the original on 2019-04-20. Retrieved 2019-04-19.
  • Calingaert, 피터(1979년)[1978-11-05]."8.2.2 Relocating 로더".노스 캐롤라이나 대학교 채플힐에 쓰여진.호로위츠에, 엘리스(교육.).Assemblers, 컴파일러, 그리고 프로그램 번역.컴퓨터 소프트웨어 공학 시리즈(1인쇄 1일 교육.).포토맥, 마릴랜드, USA:컴퓨터 과학 출판 주식 회사 pp. 237–241.아이 에스비엔 0-914894-23-4.ISSN 0888-2088.LCCN 78-21905..(2+xiv+270+6 페이지)2020-03-20 Retrieved
  • The Microsoft OBJ File Format. Microsoft, Product Support Services. Application Note SS0288. Archived from the original on 2017-09-09. Retrieved 2017-08-21.
  • Tanenbaum, Andrew Stuart; Bos, Herbert (2015). Modern Operating Systems (4 ed.). Pearson Education Inc. ISBN 978-0-13359162-0.
  • Elliott, John C. (2012-06-05) [2000-01-02]. "PRL file format". seasip.info. Archived from the original on 2020-01-26. Retrieved 2020-01-26. […] A PRL file is a relocatable binary file, used by MP/M and CP/M Plus for various modules other than .COM files. The file format is also used for FID files on the Amstrad PCW. There are several file formats which use versions of PRL: SPR (System PRL), RSP (Resident System Process). LINK-80 can also produce OVL (overlay) files, which have a PRL header but are not relocatable. GSX drivers are in PRL format; so are Resident System Extensions (.RSX). […] [9]
  • Elliott, John C. (2012-06-05) [2000-01-02]. "Microsoft REL format". seasip.info. Archived from the original on 2020-01-26. Retrieved 2020-01-26. […] The REL format is generated by Microsoft's M80 and Digital Research's RMAC. […]
  • feilipu (2018-09-05) [2018-09-02]. "Support for PRL, page relocatable executable for MP/M". z88dk. Archived from the original on 2020-02-01. Retrieved 2020-01-26. […] Out of the assembled Microsoft .REL files the linker has to generate a .PRL format executable for MP/M. The .PRL format is essentially a .COM file with some additional information to enable the program and its data to be relocated onto any page. What does a .PRL file look like? The first bytes are size of the program, followed by the program origin at 0x0100. Following the program, there is a bit-for-byte mask appended to allow the MP/M system to know which bytes in the program need to be changed when the program is relocated. How does the linker do that without disassembling the whole application? In advance the program is linked for two different origins 0x0100 and 0x0200, from the .REL objects. The linker trick is simply recognising which bytes in the two versions of the executable differ. These bytes are then recorded in the bit mask stored following the executable, and the final .PRL program is designed to run from 0x0100 plus its page offset. The same trick is done for the .RSP and .SPR executable files, except that both these formats forego the offset, and run from 0x0000 plus their page offset. […]
  • Brothers, Hardin (April 1983). "Understanding Relocatable Code". 80 Micro. The Next Step. 1001001, Inc. (39): 38, 40, 42, 45. ISSN 0744-7868. Retrieved 2020-02-06. [10][11]
  • Brothers, Hardin (April 1985). "Relocatable Programs: Microcomputing's Hoboes". 80 Micro. The Next Step. CW Communications/Peterborough, Inc. (63): 98, 100, 102–103. ISSN 0744-7868. Retrieved 2020-02-06. [12][13]
  • Sage, Jay (May–June 1988). Carlson, Art (ed.). "ZCPR 3.4 - Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (32): 10–17 [15–16]. ISSN 0748-9331. ark:/13960/t1wd4v943. Retrieved 2021-11-29. [14][15]
  • Mitchell, Bridger (July–August 1988). Carlson, Art (ed.). "Z3PLUS & Relocation - Information on ZCPR3PLUS, and how to write self relocating Z80 code". The Computer Journal (TCJ) - Programming, User Support, Applications. Advanced CP/M. Columbia Falls, Montana, USA (33): 9–15. ISSN 0748-9331. ark:/13960/t36121780. Retrieved 2020-02-09. [16][17]
  • Sage, Jay (September–October 1988). Carlson, Art (ed.). "More on relocatable code, PRL files, ZCPR34, and Type-4 programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (34): 20–25. ISSN 0748-9331. ark:/13960/t0ks7pc39. Retrieved 2020-02-09. [18][19][20]
  • Sage, Jay (January–February 1992). Carlson, Art; McEwen, Chris (eds.). "Ten Years of ZCPR". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner. S. Plainfield, New Jersey, USA: Socrates Press (54): 3–7. ISSN 0748-9331. ark:/13960/t89g6n689. Retrieved 2021-11-29. [21][22][23]
  • Sage, Jay (May–June 1992) [March–June 1992]. Carlson, Art; McEwen, Chris (eds.). "Type-3 and Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner - Some New Applications of Type-4 Programs. S. Plainfield, New Jersey, USA: Socrates Press (55): 13–19. ISSN 0748-9331. ark:/13960/t4dn54d22. Retrieved 2021-11-29. [24][25]
  • Ganssle, Jack (February 1992). "Writing Relocatable Code - Some embedded code must run at more than one address". Embedded Systems Programming. The Ganssle Group - Perfecting the Art of Building Embedded Systems / TGG. Archived from the original on 2019-07-18. Retrieved 2020-02-20.