KR20120114926A - 바이너리 실행파일 생성을 위한 프로그래밍 방법 - Google Patents

바이너리 실행파일 생성을 위한 프로그래밍 방법 Download PDF

Info

Publication number
KR20120114926A
KR20120114926A KR1020110032775A KR20110032775A KR20120114926A KR 20120114926 A KR20120114926 A KR 20120114926A KR 1020110032775 A KR1020110032775 A KR 1020110032775A KR 20110032775 A KR20110032775 A KR 20110032775A KR 20120114926 A KR20120114926 A KR 20120114926A
Authority
KR
South Korea
Prior art keywords
binary
platform
file
code
application
Prior art date
Application number
KR1020110032775A
Other languages
English (en)
Inventor
김민근
Original Assignee
주식회사 아이리버
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 아이리버 filed Critical 주식회사 아이리버
Priority to KR1020110032775A priority Critical patent/KR20120114926A/ko
Publication of KR20120114926A publication Critical patent/KR20120114926A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

본 발명은 바이너리 실행파일 생성을 위한 프로그래밍 방법에 관한 것이다. 본 발명은 실행하고자 하는 어플리케이션에 대한 소스 코드를 작성하는 단계와, 작성된 소스코드를 컴파일러 과정을 수행하여 어셈블리 코드로 변환하는 단계와, 상기 변환된 어셈블리 코드를 바이너리 코드로 변환하고, 링크를 수행하여 제 1 바이너리 파일을 생성하는 단계와, 상기 제 1 바이너리 파일에 대해 2진 파일을 재배치하여 다양한 SoC 솔루션에 포팅(porting) 되기 위해 규격화된 인터페이스를 제공하는 플랫폼에서 실행 가능한 제 2 바이너리 파일을 생성하는 단계를 포함하여 이루어진다. 그리고 제 2 바이너리 파일은, 어플리케이션의 크기에 따라 가변되는 크기를 가지되, '헤더(Header)', '읽기 전용(read-only)' 섹션, '읽기-쓰기(read-write)' 섹션, '재배치(relocation)' 섹션, '임포트(import)' 섹션, '리소스(resource)' 섹션 및 복수의 'extra' 섹션을 포함하여 구성된다. 그와 같은 본원발명에 따르면, SoC 솔루션의 운영체제와 상관없이 로딩되어 바로 실행될 수 있기 때문에, 종래 다른 운영체제에 제공된 실행파일을 실행시키기 위해 실행파일 마다 수행해야 하는 컴파일 과정을 생략할 수 있는 이점이 있다.

Description

바이너리 실행파일 생성을 위한 프로그래밍 방법{METHOD FOR PROGRAMMING FOR A BINARY EXECUTABLE FILE}
본 발명은 프로그래밍 모델에 관한 것으로, 특히 여러 SoC 솔루션에 포팅되기 위해 규격화된 인터페이스를 제공하는 플랫폼 구조에서 어플리케이션를 실행하기 위한 실행파일이 운영체제와 상관없이 구동될 수 있게 하기 위하여 플랫폼 구조에 맞는 바이너리 실행파일을 생성하기 위한 프로그래밍 방법에 관한 것이다.
어플리케이션 파일을 실행시키기 위한 실행파일은 프로그래머가 C- 소스 코드를 작성하면, 그 C-소스 코드를 컴파일(compile) 및 링크(link) 과정을 수행하여 생성한다.
이러한 과정을 도 1을 참조하여 개략적으로 설명한다. 도 1은 일반적인 실행파일의 프로그래밍 모델을 설명하는 블록구성도이다.
먼저 프로그래머는 실행하고자 하는 어플리케이션에 대한 C- 언어를 사용하여 C-소스 코드를 작성한다(s10).
작성된 상기 C- 소스 코드에 대해 어셈블리 코드로 변환하는 컴파일러를 수행한다(s12).
그러면 어셈블리 코드가 생성되고, 이를 바이너리 코드로 변환하는 어셈블러를 수행한다(s14). 어셈블러에 의해 0 및 1의 코드로 되어있는 바이너리 코드로 변환된다.
이후, 바이너리 코드에 대해 링크를 수행하면(s16), 특정 운영체제에서 구동 가능한 실행파일이 생성된다. 여기서 상기 실행파일을 네이티브 바이너리(Native Binary)라고 하기로 한다.
이렇게 생성된 실행파일은 단말장치의 운영체제에서 로딩되어 실행되고, 따라서 그에 맞는 어플리케이션이 실행되게 된다.
상기한 실행파일의 예로, Win 32 운영체제하에서는 PE(Portable Executable) 형식의 파일로서 .EXE 파일 및 .DLL 파일 등이 있다. 이는 시스템 플랫폼에 관계없이 Win32 운영 체제가 운용되는 시스템이면 어디서든 실행 가능하다. 다른 예로 리눅스 운영체제의 'ELF' 파일이 있다.
하지만, 상기의 실행파일은 Win 32 운영체제 및 리눅스 운영체제를 각각 기반으로 하고 있다. 이에 각각의 실행파일은 자신의 운영체제가 아닌 다른 운영체제에서는 실행할 수 없었다.
따라서, 소정의 운영체제하에서 실행이 불가능한 실행파일을 그 운영체제에서 구동시키기 위해서는 실행파일을 만들 때마다 그 운영체제에 맞게 컴파일 과정을 수행해야만 했다.
즉, 이처럼 특정 실행파일은 비록 자신의 운영체제에서는 로딩된 후 바로 실행될 수 있었지만, 다른 운영체제의 환경하에서는 구동에 필요한 컴파일 작업이 반드시 필요하였던 것이다.
이러한 이유로, 다양한 SoC 솔루션에 각 기능별로 추상화된 복수의 인터페이스가 포팅된 플랫폼 구조에서만 사용 가능한 어플리케이션 실행을 위한 독자적인 실행파일 포맷이 제공될 수 있다면, 컴파일 및 링크 과정을 수행하지 않고서도 운영체제와 상관없이 실행파일을 로딩할 수 있을 것이다.
따라서 본 발명의 목적은 상기한 문제점을 해결하기 위한 것으로, 여러 SoC 솔루션에 포팅되기 위해 규격화된 인터페이스를 제공하는 플랫폼 구조에서 운영체제의 형식과 상관없이 구동되는 실행파일을 생성하기 위한 프로그래밍 모델을 제공하는 것이다.
상기한 목적을 달성하기 위한 본 발명의 특징에 따르면, 실행하고자 하는 어플리케이션에 대한 소스 코드를 작성하는 단계; 작성된 소스코드를 컴파일러 과정을 수행하여 어셈블리 코드로 변환하는 단계; 상기 변환된 어셈블리 코드를 바이너리 코드로 변환하고, 링크를 수행하여 제 1 바이너리 파일을 생성하는 단계; 그리고 상기 제 1 바이너리 파일에 대해 2진 파일을 재배치하여 특정 플랫폼에서 실행 가능한 제 2 바이너리 파일을 생성하는 단계를 포함하여 이루어진다.
여기서, 상기 특정 플랫폼은, 다양한 SoC 솔루션에 포팅(porting) 되기 위해 규격화된 인터페이스를 제공하는 플랫폼임을 특징으로 한다.
그리고 상기 플랫폼은, 상기 SoC 솔루션에 의하여 구현되는 규격화된 복수의 인터페이스를 포함하는 플랫폼 추상화 레이어(platform abstraction layer)와, 상기 플랫폼 추상화 레이어의 인터페이스를 사용하여 작성되며 상기 플랫폼의 동작 메커니즘을 구현하는 코어 레이어(core layer)와, 어플리케이션 개발에 필요한 어플리케이션 인터페이스(API)를 상기 코어 레이어의 각 컴포넌트가 가진 인터페이스를 통해 구현하는 어플리케이션 프로그래밍 인터페이스 레이어(API layer)를 포함하여 구성한다.
또한, 상기 제 2 바이너리 파일은, 어플리케이션의 크기에 따라 가변되는 크기를 가지되, '헤더(Header)', '읽기 전용(read-only)' 섹션, '읽기-쓰기(read-write)' 섹션, '재배치(relocation)' 섹션, '임포트(import)' 섹션, '리소스(resource)' 섹션 및 복수의 'extra' 섹션을 포함하여 이루어진다.
위와 같은 본 발명의 바이너리 실행파일 생성을 위한 프로그래밍 방법에 따르면 다음과 같은 효과가 있다.
즉, 본 발명은 일반적인 실행파일을 생성하는 프로그래밍 방법에 추가하여 그 생성된 실행파일의 2진 파일을 재배치하는 과정을 수행하여, 다양한 SoC 솔루션에 포팅되기 위해 규격화된 인터페이스를 제공하는 플랫폼 구조에서 실행되는 바이너리 실행파일을 생성하고 있다.
이러한 바이너리 실행파일은 헤더(header), 읽기전용 섹션, 읽기- 쓰기 섹션, 재배치 섹션, 임포트 섹션 및 리소스 섹션을 포함하는 독자적인 포맷으로 구성되어 있다.
따라서, 상기의 플랫폼에서 SoC 솔루션의 운영체제와 상관없이 로딩되어 바로 실행될 수 있기 때문에, 종래 다른 운영체제에 제공된 실행파일을 실행시키기 위해 실행파일마다 수행해야 하는 컴파일 과정을 생략할 수 있고, 본 발명에 따라 생성된 바이너리 실행파일을 지원하는 플랫폼이 탑재된 단말장치가 제공되면, 종래 단말장치 별로 운영체제가 서로 달라 실행파일을 구동시키는데 따른 제약을 방지할 수 있어, 개발자의 개발 환경 및 사용자의 사용 환경에 대한 편의성을 증대시킬 수 있다.
도 1은 일반적인 실행파일의 프로그래밍 모델을 설명하는 블록구성도
도 2는 본 발명의 바람직한 실시 예에 따라 특정 플랫폼 구조에서 구동되는 바이너리 실행파일을 생성하는 프로그래밍 모델 구성도
도 3은 본 발명의 프로그래밍 모델에 따라 생성된 바이너리 실행파일의 구조도
이하 본 발명에 의한 바이너리 실행파일의 생성을 위한 프로그래밍 모델를 첨부된 도면에 도시된 바람직한 실시 예를 참조하여 상세하게 설명한다.
우선하여, 본 발명의 바이너리 실행파일은 특정한 플랫폼 구조에서 실행되는 것에 유의해야 한다. 즉, 플랫폼 구조는 본 발명에 따른 프로그래밍 모델에 의하여 생성되는 바이너리 실행파일을 지원하는 구조이다. 이러한 구조는 플랫폼 추상화 레이어(platform abstraction layer), 코어 레이어(core layer) 및 어플리케이션 프로그래밍 인터페이스 레이어(API layer)의 3가지 층 구조를 가진다. 또 실행파일에 의해 구동되는 적어도 하나 이상의 어플리케이션(Application) 및 과 SoC 솔루션 모듈이 구성된다.
그리고, 상기 플랫폼 추상화 레이어는 다양한 SoC 솔루션에 포팅되기 위하여 그 SoC 솔루션을 추상화하고, SoC 솔루션과 독립적으로 구현할 수 있게 규격화된 인터페이스를 제공하는 역할을 한다.
이처럼 플랫폼 추상화 레이어가 SoC 솔루션에 포팅된 플랫폼 구조에서는 아래에서 설명되는 본 실시 예의 프로그래밍 모델에 의해 생성된 바이너리 실행파일은 SoC 솔루션에 탑재된 운영체제와 상관없이 실행될 수 있다.
이어 상기 플랫폼 구조에서 실행되는 바이너리 실행파일을 생성하는 프로그래밍 모델을 도 2를 참조하여 설명하기로 한다.
먼저 프로그래머는 실행하고자 하는 어플리케이션에 대한 C- 언어를 사용하여 C-소스 코드를 작성한다(s100). 이는 상기 플랫폼 구조가 바이너리 실행환경을 제공하고, 플랫폼에서 구동되는 어플리케이션이 C- 언어로 프로그래밍 되기 때문이다.
상기 C- 소스 코드가 작성되면, 필요한 라이브러리를 호출하여 어셈블리 코드로 변환하는 컴파일러 과정을 수행한다(s102).
이에, C-소스 코드는 어셈블리 코드로 생성되며, 다시 어셈블러 과정을 수행하여 어셈블리 코드를 바이너리 코드로 변환한다(s104). 그래서 0 및 1의 코드로 되어있는 코드로 변환된다.
그리고 바이너리 코드에 대해 링크(link)를 수행하면(s106), 표준의 실행파일이 생성된다(s108). 여기서 상기 실행파일을 네이티브 바이너리(Native Binary)라고 하기로 하고, 이 실행파일은 특정한 운영체제에서만 실행되는 파일이다.
이후, 상기 네이티브 바이너리에 대해 2진 파일을 재배치하는 과정(즉, 포스트 링커-post linker)을 수행한다(s108).
이에, 상술한 플랫폼 구조가 인식할 수 있는 바이너리 실행파일이 생성된다(s112). 즉, 상기 포스트 링커 과정은 일반적인 실행파일 형태를 본 발명에서 제안하고 있는 플랫폼에서 실행될 수 있는 포맷으로 변환/생성하는 과정이라 할 수 있다.
이처럼, 포스트 링커 과정에 의해 특정 어플리케이션에 대한 바이너리 실행파일이 생성되면, SoC 솔루션에 포팅되기 위해 규격화된 인터페이스를 제공하는 플랫폼을 가지는 어떠한 단말장치에서도 운영체제의 종류와 상관없이 운영체제에 로딩되어 실행될 수 있다.
한편, 본 발명의 프로그래밍 방법에 의해 생성된 상술한 바이너리 실행파일의 구조도 3에 도시하고 있다.
즉, '헤더(Header)', '읽기 전용(read-only)' 섹션, '읽기-쓰기(read-write)' 섹션, '재배치(relocation)' 섹션, '임포트(import)' 섹션, '리소스(resource)' 섹션 및 복수의 'extra' 섹션과 같이 여러 개의 섹션을 포함하고 있다.
'헤더'는, 바이너리 실행파일의 구조 정보를 제공한다. 즉, 상술한 복수의 섹션에 대한 각각의 정보와 생성날짜, 타입(type), 어플리케이션의 엔트리 주소에 관한 정보를 포함한다. 이는 'struct flow_exe_header' 구조체에 의해 다음 [표 1]로 기술될 수 있다.
Figure pat00001
그리고, 상기 구조체에는 'flow_section_info'의 구조체는 다음 [표 2]와 같이 기술될 수 있다.
Figure pat00002
여기서, 상기 offset 필드는 파일의 시작부터 섹션까지의 오프셋 바이트(byte)를 나타내고, size 필드는 섹션의 바이트(byte) 단위의 사이즈를 나타낸다. 참고로, 상기 [표 1] 및 [표 2]와 본 실시 예의 상세한 설명에 전반적으로 기재된 flow는 상기 포팅 플랫폼을 지칭한다.
한편, 상기 [표 1]에 기재하고 있는 Identity 필드의 각각의 인덱스는 바이너리 실행파일의 타입에 관한 정보를 나타낸다. 이는 다음 [표 3]에 기재하고 있다.
index 값
0 ASCII 'F'
1 ASCII 'E'
2 ASCII 'B'
3 Target CPU 아키텍처
4 Data Encoding Endian
5 File Format Version
6 Underfined
7 Underfined
[표 3]에서 index 3은 바이너리 실행파일이 실행되는 프로세서의 아키텍처를 2개의 값으로 나타내고 있고, '0' 값이면 'none'이고 '1' 값이면 'ARM core' 아키텍처이다. 또한 index 4는 바이너리 실행파일이 가지는 바이너리 데이터의 엔코딩 타입을 3가지 타입으로 말하는 것으로, '0' 값이면 'none' 타입, '1' 값이면 'Little Endian' 타입, '2' 값이면 'Big Endian' 타입을 가리킨다.
계속해서, 상기 [표 1]의 'read_only'는 바이너리 실행파일에서 읽기 전용인 'Read-only' 영역에 대한 오프셋과 사이즈를 나타내고, 'read_write'는 바이너리 실행파일에서 읽기- 쓰기인 'Read-Write' 영역에 대한 오프셋과 사이즈를 나타낸다.
또 바이너리 실행파일 내에는 존재하지 않는 필드로서 제공되는 'zero_init'는 어플리케이션이 메모리에 로딩될 때 필요한 'Zero-Initialized' 영역에 대한 메모리 내의 바이너리 실행파일의 시작부터 ZI 영역까지의 오프셋과 사이즈를 나타낸다.
또 재배치인 'relocation'은 재배치 영역의 오프셋과 사이즈, 'Import'는 임포트 영역에 대한 오프셋과 사이즈, 'resource'는 리소스 영역에 대한 오프셋과 사이즈, 'extra1' 및 'extra2'는 각각의 영역에 대한 오프셋과 사이즈를 나타낸다.
또 'entry 1' 및 'entry 2'는 바이너리 실행파일 내의 entry 1 및 entry 2 함수에 대한 오프셋을 나타낸다.
다음으로 읽기전용(read-only) 섹션이다.
읽기전용 섹션은 어플리케이션의 코드와 읽기전용(read-Only) 데이터 영역을 가진다. 본 바이너리 실행파일이 구동되는 포팅 플랫폼에서는 코드에 대한 재배치는 하지 않는 대신 PIC(Position independ Code)로 컴파일한다. 이는 바이너리 실행파일을 빠르게 실행시키기 위함이다.
다음, 읽기-쓰기(read-write) 섹션이다.
읽기-쓰기 섹션은 어플리케이션의 읽기- 쓰기(Read-Write) 데이터 영역을 가진다.
다음, 재배치(Relocation) 섹션이다.
본 실시 예에 따른 포팅 플랫폼은 바이너리 실행파일을 리드(read)하여 임의의 메모리 주소에 위치시킨다. 이때 포팅 플랫폼은 재배치 섹션 영역에 있는 정보를 리드(read)하여 재배치를 수행한다.
여기서 재배치 섹션의 데이터는 다음 [표 4]와 같은 구조체의 연속으로 이루어진다.
Figure pat00003
[표 4]에서 offset는 재배치가 수행되어야 할 위치로 메모리에 로드된 바이너리 실행파일의 시작위치를 말한다. 그리고 type은 재배치 타입을 나타내는 것으로, 각 타입에 따른 재배치는 다음 [표 5]에 정리하고 있다.
값 Type 설명
0 None Invalid Value
1 FEB_RES_ABASE 메모리상의 이미지 시작 주소를 더한다.
그리고 [표 4]에서 'addend'는 재배치할 때 필요한 보정값을 말한다.
다음, 임포트(Import) 섹션이다.
이 섹션에는 어플리케이션이 사용하는 동적 라이브러리의 파일 이름 정보를 저장하고 있다. 따라서 바이너리 실행파일이 실행될 때 포팅 플랫폼은 상기 섹션에 저장된 동적 라이브러리의 파일 중 필요한 라이브러리를 로딩한다.
다음, 리소스(resource) 섹션이다.
이 섹션은 어플리케이션이 사용하는 리소스 정보를 저장하고 있다. 즉, 어플리케이션은 코드 및 데이터 이외에도 각종 리소스 정보를 포함하고 있다. 리소스 정보의 예로 음악, 그림, 사용자 데이터 등을 말할 수 있다.
그리고 상기 리소스 섹션은 다음 [표 6]과 같은 형태로 제공된다. 즉, 먼저 리소스에 대한 정보 리스트가 나열되고 다음에 리소스 데이터가 나열된다.
0번째 리소스 정보
1번째 리소스 정보
2번째 리소스 정보
…
N번째 리소스 정보
null 리소스 정보
0번째 리소스 데이터
1번째 리소스 데이터
2번째 리소스 데이터
…
nqjsWo 리소스 데이터
이러한 리소스 정보는 [표 7]과 같은 구조체이다.
Figure pat00004
여기서, offset은 리소스 섹션의 시작부터 해당 리소스까지의 오프셋이고, size은 리소스의 크기이고, type은 리소스 타입이다. 리소스 타입은 다음 [표 8]과 같이 정의된다.
값 type 설명
0 FEB_RES_TYPE_NONE invalid Value
1 FEB_RES_TYPE_UNICODE_STRING 유니코드 문자열
2 FEB_RES_TYPE_STRING 문자열
3 FEB_RES_TYPE_BMP bmp 포맷 이미지
4 FEB_RES_TYPE_JPG jpg 포맷 이미지
5 FEB_RES_TYPE_PNG png 포맷 이미지
이처럼, 본 실시 예에 따르면 어플리케이션에 대한 바이너리 실행파일을 생성하여 제공하고 있어, 운영체제별로 어플리케이션용 실행파일을 각각 만들어야 하는 불편함을 없앨 수 있다.
이상과 같이 본 발명의 도시된 실시 예를 참고하여 설명하고 있으나, 이는 예시적인 것들에 불과하며, 본 발명의 속하는 기술분야의 통상 지식을 가진 자라면 본 발명의 요지 및 범위에 벗어나지 않으면서도 다양한 변형, 변경 및 균등한 타 실시 예들이 가능하다는 것을 명백하게 알 수 있을 것이다. 따라서 본 발명의 진정한 기술적 보호 범위는 첨부된 청구범위의 기술적인 사상에 의해 정해져야 할 것이다.

Claims (4)

  1. 실행하고자 하는 어플리케이션에 대한 소스 코드를 작성하는 단계;
    작성된 소스코드를 컴파일러 과정을 수행하여 어셈블리 코드로 변환하는 단계;
    상기 변환된 어셈블리 코드를 바이너리 코드로 변환하고, 링크를 수행하여 제 1 바이너리 파일을 생성하는 단계; 그리고
    상기 제 1 바이너리 파일에 대해 2진 파일을 재배치하여 특정 플랫폼에서 실행 가능한 제 2 바이너리 파일을 생성하는 단계를 포함하여 수행하는 바이너리 실행파일 생성을 위한 프로그래밍 방법.
  2. 제 1 항에 있어서, 상기 특정 플랫폼은,
    다양한 SoC 솔루션에 포팅(porting) 되기 위해 규격화된 인터페이스를 제공하는 플랫폼임을 특징으로 하는 바이너리 실행파일 생성을 위한 프로그래밍 방법.
  3. 제 2 항에 있어서, 상기 플랫폼은,
    상기 SoC 솔루션에 의하여 구현되는 규격화된 복수의 인터페이스를 포함하는 플랫폼 추상화 레이어(platform abstraction layer)와, 상기 플랫폼 추상화 레이어의 인터페이스를 사용하여 작성되며 상기 플랫폼의 동작 메커니즘을 구현하는 코어 레이어(core layer)와, 어플리케이션 개발에 필요한 어플리케이션 인터페이스(API)를 상기 코어 레이어의 각 컴포넌트가 가진 인터페이스를 통해 구현하는 어플리케이션 프로그래밍 인터페이스 레이어(API layer)를 포함하여 구성하는 바이너리 실행파일 생성을 위한 프로그래밍 방법.
  4. 제 1 항에 있어서, 상기 제 2 바이너리 파일은,
    어플리케이션의 크기에 따라 가변되는 크기를 가지되,
    '헤더(Header)', '읽기 전용(read-only)' 섹션, '읽기-쓰기(read-write)' 섹션, '재배치(relocation)' 섹션, '임포트(import)' 섹션, '리소스(resource)' 섹션 및 복수의 'extra' 섹션을 포함하여 이루어짐을 특징으로 하는 바이너리 실행파일 생성을 위한 프로그래밍 방법.
KR1020110032775A 2011-04-08 2011-04-08 바이너리 실행파일 생성을 위한 프로그래밍 방법 KR20120114926A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020110032775A KR20120114926A (ko) 2011-04-08 2011-04-08 바이너리 실행파일 생성을 위한 프로그래밍 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020110032775A KR20120114926A (ko) 2011-04-08 2011-04-08 바이너리 실행파일 생성을 위한 프로그래밍 방법

Publications (1)

Publication Number Publication Date
KR20120114926A true KR20120114926A (ko) 2012-10-17

Family

ID=47283968

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020110032775A KR20120114926A (ko) 2011-04-08 2011-04-08 바이너리 실행파일 생성을 위한 프로그래밍 방법

Country Status (1)

Country Link
KR (1) KR20120114926A (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112650503A (zh) * 2020-12-18 2021-04-13 广东高云半导体科技股份有限公司 一种软件编译方法及片上系统
CN117075960A (zh) * 2023-10-17 2023-11-17 统信软件技术有限公司 程序重构方法、应用跨平台迁移方法、装置与计算设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112650503A (zh) * 2020-12-18 2021-04-13 广东高云半导体科技股份有限公司 一种软件编译方法及片上系统
CN112650503B (zh) * 2020-12-18 2022-06-17 广东高云半导体科技股份有限公司 一种软件编译方法及片上系统
CN117075960A (zh) * 2023-10-17 2023-11-17 统信软件技术有限公司 程序重构方法、应用跨平台迁移方法、装置与计算设备
CN117075960B (zh) * 2023-10-17 2024-01-23 统信软件技术有限公司 程序重构方法、应用跨平台迁移方法、装置与计算设备

Similar Documents

Publication Publication Date Title
US10367822B2 (en) Restrictive access control for modular reflection
US11347489B2 (en) Accessing a migrated member in an updated type
US11366643B2 (en) Generating dynamic modular proxies
US20160232017A1 (en) System and Method for Reloading Constructors
US10140119B2 (en) Modular serialization
US10789047B2 (en) Returning a runtime type loaded from an archive in a module system
US11366684B2 (en) Import mechanism for hardware intrinsics
US20040268301A1 (en) Adding new compiler methods to an integrated development environment
US8606766B2 (en) Method and system to handle java class versioning
US10846417B2 (en) Identifying permitted illegal access operations in a module system
US11048489B2 (en) Metadata application constraints within a module system based on modular encapsulation
US10387142B2 (en) Using annotation processors defined by modules with annotation processors defined by non-module code
KR20120114926A (ko) 바이너리 실행파일 생성을 위한 프로그래밍 방법
CN116243971B (zh) 一种基于静态依赖自举的内核无关的模块构建方法
KR20120114924A (ko) 바이너리 실행파일 포맷 구조
JP2001142719A (ja) コンパイラ装置及びコンパイラプログラムを記録した記録媒体
WO2017034652A1 (en) Restrictive access control for modular reflection

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination