我们遇到了一个与在Advantech POS板上使用Via C3处理器在(相当旧的)FC3下运行的Java应用程序相关的问题.java应用程序有几个已编译的共享库,可通过JNI访问.
通过C3处理器应该是i686兼容.前段时间在使用相同处理器的MiniItx主板上安装Ubuntu 6.10之后,我发现之前的声明并非100%正确.由于缺少C3处理器中i686设置的一些特定和可选指令,Ubuntu内核在启动时挂起.在使用i686优化时,GCC编译器默认使用i686集的C3实现中缺少的这些指令.在这种情况下,解决方案是使用i386编译版本的Ubuntu发行版.
Java应用程序的基本问题是通过克隆另一台PC的HD映像来安装在HD上的FC3发行版,这次是Intel P4.之后,分发需要一些黑客才能让它运行,比如用i386编译的版本替换一些软件包(例如内核).
问题是,工作一段时间后系统完全挂起而没有任何痕迹.我担心一些i686代码会留在系统中的某个地方,并且可以随时随机执行(例如从暂停模式或类似的东西中恢复后).
我的问题是:
是否有任何工具或方法可以找出二进制文件(可执行文件或库)所需的特定体系结构扩展?file
没有提供足够的信息.
Tim Kane.. 106
unix.linux file
命令非常适用于此.它通常可以检测给定二进制文件的目标体系结构和操作系统(并且自1973年以来一直保持打开和关闭状态.哇!)
当然,如果你没有在unix/linux下运行 - 你有点卡住了.我目前正在尝试找到一个可以在运行时调用的基于java的端口..但没有这样的运气.
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
使用(unix)objdump -f
命令提示有关体系结构详细信息的更多详细信息,该命令返回:
architecture: arm, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0000876c
这个可执行文件是由gcc交叉编译器编译的(在i86机器上编译,用于ARM处理器作为目标)
unix.linux file
命令非常适用于此.它通常可以检测给定二进制文件的目标体系结构和操作系统(并且自1973年以来一直保持打开和关闭状态.哇!)
当然,如果你没有在unix/linux下运行 - 你有点卡住了.我目前正在尝试找到一个可以在运行时调用的基于java的端口..但没有这样的运气.
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
使用(unix)objdump -f
命令提示有关体系结构详细信息的更多详细信息,该命令返回:
architecture: arm, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0000876c
这个可执行文件是由gcc交叉编译器编译的(在i86机器上编译,用于ARM处理器作为目标)
我决定为这里的任何人添加一个解决方案:在我的情况下,个人提供的信息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
我认为你需要一个检查每条指令的工具,以确定它属于哪个集合.是否有C3处理器实现的特定指令集的官方名称?如果没有,它甚至更加毛茸茸.
如果您可以确定不允许的指令的位模式,那么quick'n'dirty变体可能是在文件中进行原始搜索.只需直接测试它们,就可以通过一个简单的objdump | grep
链来完成.
为了回答Via C3是否是i686级处理器的模糊性:它不是,它是i586级处理器.
Cyrix从未生产出真正的686级处理器,尽管他们对6x86MX和MII部件进行了营销宣传.在其他缺失的指令中,他们没有的两个重要指令是CMPXCHG8b和CPUID,它们是运行Windows XP及更高版本所必需的.
美国国家半导体,AMD和VIA都生产了基于Cyrix 5x86/6x86核心(NxP MediaGX,AMD Geode,VIA C3/C7,VIA Corefusion等)的CPU设计,这些设计导致了具有586级处理器的古怪设计使用SSE1/2/3指令集.
我的建议是,如果您遇到上面列出的任何CPU,并且它不适用于老式计算机项目(即Windows 98SE和之前的版本),那么就会尖叫远离它.您将被困在慢速i386/486 Linux上,或者必须使用特定于Cyrix的优化重新编译所有软件.