Linux (라이브러리 또는 실행 파일)에서 바이너리 파일의 대상 ISA 확장을 결정합니다.
Via C3 프로세서가있는 어드밴텍 POS 보드의 (오래된) FC3에서 실행되는 Java 애플리케이션과 관련된 문제가 있습니다. Java 애플리케이션에는 JNI를 통해 액세스되는 여러 컴파일 된 공유 라이브러리가 있습니다.
Via C3 프로세서는 i686과 호환되어야합니다. 얼마 전 동일한 프로세서를 사용하는 MiniItx 보드에 Ubuntu 6.10을 설치 한 후 이전 진술이 100 % 사실이 아니라는 것을 알게되었습니다. C3 프로세서에 설정된 i686의 일부 특정 및 선택적 지침이 없기 때문에 Ubuntu 커널이 시작시 중단되었습니다. i686 세트의 C3 구현에서 누락 된 이러한 명령어는 i686 최적화를 사용할 때 GCC 컴파일러에서 기본적으로 사용됩니다. 이 경우 해결책은 Ubuntu 배포판의 i386 컴파일 버전을 사용하는 것이 었습니다.
Java 응용 프로그램의 기본 문제는 FC3 배포판이 다른 PC (이번에는 Intel P4)의 HD 이미지에서 복제하여 HD에 설치되었다는 것입니다. 그 후 배포판은 일부 패키지 (예 : 커널 패키지)를 i386 컴파일 된 버전으로 교체하는 등 일부 해킹이 필요했습니다.
문제는 잠시 작업 한 후 시스템이 흔적없이 완전히 중단된다는 것입니다. 일부 i686 코드가 시스템 어딘가에 남아 있고 언제든지 무작위로 실행될 수 있다는 점이 두렵습니다 (예 : 일시 중지 모드 등에서 복구 한 후).
내 질문은 :
- 바이너리 파일 (실행 파일 또는 라이브러리)에 필요한 특정 아키텍처 확장을 찾을 수있는 도구 나 방법이 있습니까?
file충분한 정보를 제공하지 않습니다.
정확히 어떤 세트에 속하는지 결정하기 위해 모든 명령을 확인하는 도구가 필요하다고 생각합니다. C3 프로세서에 의해 구현 된 특정 명령 집합에 대한 공식적인 이름이 있습니까? 그렇지 않다면 더 털이 있습니다.
허용되지 않는 명령어의 비트 패턴을 확인할 수있는 경우 빠르고 더러운 변형은 파일에서 원시 검색을 수행하는 것일 수 있습니다. objdump | grep예를 들어 간단한 체인으로 직접 테스트 할 수 있습니다 .
unix.linux file명령은 이에 적합합니다. 일반적으로 주어진 바이너리에 대한 대상 아키텍처 및 운영 체제를 감지 할 수 있습니다 (1973 년 이후로 유지 관리되고 있습니다. 와우!)
물론, 당신이 유닉스 / 리눅스에서 실행하고 있지 않다면-당신은 약간 갇혀 있습니다. 나는 현재 내가 런타임에 호출 할 수있는 자바 기반 포트를 찾으려고 노력하고있다.하지만 그런 행운은 없다.
unix file명령은 다음과 같은 정보를 제공합니다.
hex: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped
아키텍처의 세부 사항에 대한 자세한 정보는 다음 objdump -f <fileName>을 반환 하는 (unix) 명령으로 암시됩니다 .
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000876c
이 실행 파일은 gcc 크로스 컴파일러로 컴파일되었습니다 (ARM 프로세서 용 i86 머신에서 타겟으로 컴파일 됨).
나는 여기에있어 어떤 한 번 더 솔루션을 추가하기로 결정 : 개인적으로 내 경우에 의해 제공되는 정보 file와 objdump충분하지하고는 grep많이 도움이되지 않습니다 - 나는 통해 내 사건을 해결 readelf -a -W.
이것은 당신에게 많은 정보를 제공합니다. 아치 관련 정보는 맨 처음과 맨 끝에 있습니다. 예를 들면 다음과 같습니다.
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x83f8
Start of program headers: 52 (bytes into file)
Start of section headers: 2388 (bytes into file)
Flags: 0x5000202, has entry point, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 31
Section header string table index: 28
...
Displaying notes found at file offset 0x00000148 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.16
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_CPU_unaligned_access: v6
Via C3가 i686 클래스 프로세서인지 여부에 대한 모호함에 답하기 위해 : 아닙니다. i586 클래스 프로세서입니다.
Cyrix never produced a true 686 class processor, despite their marketing claims with the 6x86MX and MII parts. Among other missing instructions, two important ones they didn't have were CMPXCHG8b and CPUID, which were required to run Windows XP and beyond.
National Semiconductor, AMD and VIA have all produced CPU designs based on the Cyrix 5x86/6x86 core (NxP MediaGX, AMD Geode, VIA C3/C7, VIA Corefusion, etc.) which have resulted in oddball designs where you have a 586 class processor with SSE1/2/3 instruction sets.
My recommendation if you come across any of the CPUs listed above and it's not for a vintage computer project (ie. Windows 98SE and prior) then run screaming away from it. You'll be stuck on slow i386/486 Linux or have to recompile all of your software with Cyrix specific optimizations.
Expanding upon @Hi-Angel's answer I found an easy way to check the bit width of a static library:
readelf -a -W libsomefile.a | grep Class: | sort | uniq
Where libsomefile.a is my static library. Should work for other ELF files as well.
Quickest thing to find architecture would be to execute:
objdump -f testFile | grep architecture
This works even for binary.
'program tip' 카테고리의 다른 글
| 예기치 않은 JavaScript 가능한 반복 (0) | 2020.12.11 |
|---|---|
| 다른 기능에 영향을주지 않고 Firebase 용 Cloud Functions에 일부 기능을 배포하는 방법은 무엇입니까? (0) | 2020.12.10 |
| 분기 된 터미널에서 xcodebuild 실행 (0) | 2020.12.10 |
| 문자열에서 다음으로 변환 (0) | 2020.12.10 |
| jQuery UI 대화 상자 버튼 텍스트를 변수로 (0) | 2020.12.10 |