I have a toolchain for my target which includes a gdb client in it:
GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417-git
(It's not the latest available from GNU ARM, but I have to use it for now, so let's assume there is no latest..)
The remote target (connecting through a gdbserver connected to JTAG) in is a Cortex-A7, which is armv7-a architecture.
What I don't understand why the gdb as is from this toolchain does not list armv7-a as one of the architectures that I can with "set architecture" command, yet, it appears to debug just fine.
I build binaries for armv7-a, and verify that they are built for this arch.
I can then start the gdb from the toolchain, and load and start debugging.
If I list available inside gdb, it shows this:
set architecture
arm arm_any armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5t armv5te auto ep9312 iwmmxt iwmmxt2 xscale
No armv7 anywhere. Yet gdb doesn't complain about anything, I can debug/single step instruction code, and, I see some v7 / new instructions which are new to the architecture.
These posts somewhat related but not answering it:
How does GDB determine ARM architecture
GDB remote debug: can't stop the thread
Attributes from my elf
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_ABI_PCS_wchar_t: 4
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_enum_size: int
Tag_DIV_use: Allowed in v7-A with integer division extension
Tag_Virtualization_use: TrustZone and Virtualization Extensions
Gdb build was configured with:
configure --host=x86_64-linux-gnu --target=arm-none-eabi
What I expected is that "armv7-a" or "armv7-m" or any may be some "armv7" should be listed by gdb as supported, but it isn't .
Yet it seems to be able to work with armv7-a target code - can disassemble it and understand armv7 new instructions , such as movt/movw.
So how does it do it? Is it a special/patched gdb (client) which does not list the arch, or what am I missing?
(I've seen that later gdb versions do allow set architecture armv7-a, but that's not mine gdb, and I want to understand how mine works)
Related
I have installed Debian on qemu 64-bit ARM (followed this tutorial)
uname -a
Linux test 4.9.0-7-arm64 #1 SMP Debian 4.9.110-1 (2018-07-05) aarch64 GNU/Linux
and I am trying to run 32 bit elf files on it, but some work some don't:
bash: ./file_2: cannot execute binary file: Exec format error
running file command on the file that runs, I get:
file_1: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, not stripped
and the one that does not run:
file_2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically
linked, stripped
and both work on 32bit system(armv7l)
the only difference is that SYSV/ARM version.
is there any work around without recompiling the kernel?(read this post)
As the linked post suggests, this requires CONFIG_COMPAT to be enabled in the kernel. On the other hand I would be surprised if your kernel didn't have it -- the Debian 4.9.0-4 kernel I have from doing that tutorial does set CONFIG_COMPAT. You can check whether your kernel has it enabled by looking at the config file for it which will be in /boot/ in the guest. If it's missing then you need a new kernel, and nothing else will help.
However in your case you do have CONFIG_COMPAT, and some executables work. The difference between the ones that work and the ones that don't is that the working ones are EABI, and the non-working ones are OABI. OABI is an old and obsolete ABI for 32-bit Arm Linux binaries (the "O" stands for "old", and it's been a bad choice for a decade or so...) and it is not supported by the 64-bit kernel's CONFIG_COMPAT. You'll need to rebuild those binaries from source as EABI binaries if you want to run them under a 64-bit kernel.
I'm using Mediatek X20 dev board and gcc-linaro-6.3.1-2017.05 version
for benchmark aarch64 vs aarch32.
So I want to build binaries as 2 types of aarch32 abi : lp64, ilp32.
From gcc manual, (# [toolchain_path]/share/doc/gcc/AArch64-Options.html)
It says I can choose ilp32 and lp64 with -mabi option.
But when I use -mabi=lp64 or -mabi=ilp32, gcc makes error like below.
armv8l-linux-gnueabihf-gcc: error: unrecognized argument in option \u2018-mabi=lp64\u2019
armv8l-linux-gnueabihf-gcc: note: valid arguments to \u2018-mabi=\u2019 are: aapcs aapcs-linux apcs-gnu atpcs iwmmxt
How can I make ilp32 and lp64 formated binary?
And How can I check the binary's format?
Thanks for your reply :)
ILP32 and ILP64 are both AArch64, just one of them is limited to 32-bit addresses, but instruction encoding is the same. For that you will need to use a special toolchain. I have not tried this, but you should Google for "AArch64 ILP32 toolchain". Looks like it's not actively maintained though.
If you want AArch32, that is just ARMv7 and you need the regular arm toolchain (arm-linux-gnueabihf).
https://wiki.linaro.org/Platform/arm64-ilp32
There is now a cross-toolchain for amd64 targetting arm64ilp32 for Debian stable here:
https://people.linaro.org/~wookey/ilp32/
It's very new, but seems to work fine. Note that this targets arm64ilp32 only. If you want to also target normal arm64 (LP64) then you need to also install the aarch64-linux-gnu crosscompiler that is already in the archive.
Feedback is very welcome. The g++ cross-complier is not yet installable because there is no corresponding libstdc++:arm64ilp32 available.
Update (sept 2017). This repo now contains a debootstrappable arm64ilp32 set of packages for Debian stable.
Where can I get from the Linux kernel 3.10 for arm7l?
I tried using the one for PC but when I compile it, it ask me the processor architecture and there is no ARM option.
Thank you!
In order to configure and build it for ARM architecture set environment variables or execute the following commands sequence.
ARCH=arm
CROSS_COMPILE=your path to arm cross compile tools/bin/arm-none-eabi-
make menuconfig
Instead of default x86 there will be ARM based architectures list in the menu.
I'm trying to compile a program to run on a Linux powered board, which has an ARM926EJ-S processor. So I've installed Debian embedded cross-development toolchain, and tried compiling an Hello World with in gcc with -march=armv5te . When I tried running the binary on the board it crashed with file not found errors (due to library versions), after that I've tried compiling with -static flag and I got a seg fault (0x0000827c in __libc_start_main (), said mr gdb trough gdbserver).
Any idea on what to do here to get something running?
Apparently the solution is to try as many toolchains as you can find. Eventually you'll find the one that works, after spending a few too many hours compiling toolchains. uClibc buildroot in this case.
You can find toolchains which support ARM926EJ-S on Linaro Page. Use the most recent arm-linux-gnueabi from Linaro project. I am currently using a version with gcc 4.9.4 which you can find here
It is recommended to use -mcpu=arm926ej-s instead of -march and -mtune. See gcc documentation because it combines -march and -mtune for your specified processor. It was deprecated for x86, but not for arm.
Other possibility could be building your own toolchain via crosstools-ng. But the Linaro toolchains are working out of the box if you don't need some specific setting (for example only using static libraries).
I'm trying to use GDB to debug (to find an annoying segfault). When I run:
gdb ./filename
from the command line, I get the following error:
This GDB was configured as "i686-pc-linux-
gnu"..."/path/exec": not in executable
format: File format not recognized
When I execute:
file /path/executable/
I get the following info:
ELF 64-bit LSB executable, AMD x86-64,
version 1 (SYSV), for GNU/Linux 2.4.0,
dynamically linked (uses shared libs), not stripped
I am using GDB 6.1, and the executable is compiled with gcc version 3.4.6.
I'm a little out of my water in terms of using gdb, but as far as I can tell it should be working in this instance. Any ideas what's going wrong?
The executable is 64-bit (x86-64) and the debugger is a 32 bit (i686-pc-linux) build. You may need to install a 64-bit (x86-64) version of the debugger.
I'm not sure if this is your problem, but I faced this situation very often. The executable in the build tree, build by make/automake is not a binary, but a script, so you cannot use gdb with it. Try to install the application and change the directory, because else gdb tries to debug the script.
The question refers to "./filename" and to "/path/executable". Are these the same file?
If you are doing a post-mortem analysis, you would run:
gdb executable-file core-file
If you are going to ignore the core file, you would run:
gdb executable-file
In both cases, 'executable-file' means a pathname to the binary you want to debug. Most usually, that is actually a simple filename in the current directory, since you have the source code from your debug build there.
On Solaris, a 64-bit build of GDB is supposed to be able to debug both 32-bit and 64-bit executables (though I've had some issues with recent versions of GDB). I'm not sure of the converse - that a 32-bit GDB can necessarily debug 64-bit executables.
What you need to be checking, is really the bfd library. The binary file descriptor library is what binutils / gdb uses to actually parse and handle binaries (ELF/a.out etc..).
You can see the current supported platforms via objdump;
# objdump -H
objdump: supported targets: elf32-powerpc aixcoff-rs6000 elf32-powerpcle ppcboot elf64-powerpc elf64-powerpcle elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex
objdump: supported architectures: rs6000:6000 rs6000:rs1 rs6000:rsc rs6000:rs2 powerpc:common powerpc:common64 powerpc:603 powerpc:EC603e powerpc:604 powerpc:403 powerpc:601 powerpc:620 powerpc:630 powerpc:a35 powerpc:rs64ii powerpc:rs64iii powerpc:7400 powerpc:e500 powerpc:MPC8XX powerpc:750
The following PPC specific disassembler options are supported for use with
the -M switch:
booke|booke32|booke64 Disassemble the BookE instructions
e300 Disassemble the e300 instructions
e500|e500x2 Disassemble the e500 instructions
efs Disassemble the EFS instructions
power4 Disassemble the Power4 instructions
power5 Disassemble the Power5 instructions
power6 Disassemble the Power6 instructions
32 Do not disassemble 64-bit instructions
64 Allow disassembly of 64-bit instructions
It seems your GNU Debugger (gdb) doesn't support x86_64 architecture.
So try LLDB Debugger (lldb) which aims to replace it. It supports i386, x86-64 and ARM instruction sets.
It's available by default on BSD/OS X, on Linux install via: sudo apt-get install lldb (or use yum).
See: gdb to lldb command map page for more info.