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.
Related
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)
I am writing some code for raspberry pi ARM target on x86 ubuntu machine. I am using the gcc-linaro-armhf toolchain. I am able to cross compile and run some independent programs on pi. Now, I want to link my code with external library such as ncurses. How can I achieve this.
Should I just link my program with the existing ncurses lib on host machine and then run on ARM? (I don't think this will work)
Do I need to get source or prebuilt version of lib for arm, put it in my lib path and then compile?
What is the best practice in this kind of situation?
I also want to know how it works for the c stdlib. In my program I used the stdio functions and it worked after cross compiling without doing anything special. I just provided path for my arm gcc in makefile. So, I want to know, how it got correct std headers and libs?
Regarding your general questions:
Why the C library works:
The C library is part of your cross toolchain. That's why the headers are found and the program correctly links and runs. This is also true for some other very basic system libraries like libm and libstdc++ (not in every case, depends on the toolchain configuration).
In general when dealing with cross-development you need some way to get your desired libraries cross-compiled. Using binaries in this case is very rare. That is, especially with ARM hardware, because there are so many different configurations and often everything is stripped down much in different ways. That's why binaries are not very much binary compatible between different devices and Linux configurations.
If you're running Ubuntu on the Raspberry Pi then there is a chance that you may find a suitable ncurses library on the internet or even in some Ubuntu apt repository. The typical way, however, will be to cross compile the library with the specific toolchain you have got.
In cases when a lot and complex libraries need to be cross-compiled there are solutions that make life a bit easier like buildroot or ptxdist. These programs build complete Linux kernels and root file systems for embedded devices.
In your case, however, as long as you only want ncurses you can compile the source code yourself. You just need to download the sources, run configure while specifying your toolchain using the --host option. The --prefix option will choose the installation directory. After running make and make install, considering everything went fine, you will have got a set of headers and the ARM-compiled library for your application to link against.
Regarding cross compilation you will surely find loads of information on the internet and maybe ncurses has got some pointers in its shipped documentation, too.
For the query How the C library works in cross-tools
When compiling and building cross-tool chain during configuration they will provide sysroot.
like --with-sysroot=${CLFS_CROSS_TOOLS}
--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains (a subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched for in there. More specifically, this acts as if --sysroot=dir was added to the default options of the built compiler. The specified directory is not copied into the install tree, unlike the options --with-headers and --with-libs that this option obsoletes. The default value, in case --with-sysroot is not given an argument, is ${gcc_tooldir}/sys-root. If the specified directory is a subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved.
So instead of looking /lib /usr/include it will look /Toolchain/(libc) and (include files) when its compiling
you can check by
arm-linux-gnueabihf-gcc -print-sysroot
this show where to look for libc .
also
arm-linux-gnueabihf-gcc -print-search-dirs
gives you clear picture
Clearly, you will need an ncurses compiled for the ARM that you are targeting - the one on the host will do you absolutely no good at all [unless your host has an ARM processor - but you said x86, so clearly not the case].
There MAY be some prebuilt libraries available, but I suspect it's more work to find one (that works and matches your specific conditions) than to build the library yourself from sources - it shouldn't be that hard, and I expect ncurses doesn't take that many minutes to build.
As to your first question, if you intend to use ncurses library with your cross-compiler toolchain, you'll have its arm-built binaries prepared.
Your second question is how it works with std libs, well it's really NOT the system libc/libm the toolchain is using to compile/link your program is. Maybe you'll see it from --print-file-name= option of your compiler:
arm-none-linux-gnuabi-gcc --print-file-name=libm.a
...(my working folder)/arm-2011.03(arm-toolchain folder)/bin/../arm-none-linux-gnuabi/libc/usr/lib/libm.a
arm-none-linux-gnuabi-gcc --print-file-name=libpthread.so
...(my working folder)/arm-2011.03(arm-toolchain folder)/bin/../arm-none-linux-gnuabi/libc/usr/lib/libpthread.so
I think your Raspberry toolchain might be the same. You can try this out.
Vinay's answer is pretty solid. Just a correction when compiling the ncurses library for raspberry pi the option to set your rootfs is --sysroot=<dir> and not --with-sysroot . Thats what I found when I was using the following compiler:
arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I am trying to create a development environment on my host machine that is identical (or as close to as possible) to the one on my embedded device using a chroot. Both host and target machines are x86 so I am not attempting to cross compile. I want to build GCC in my chroot and then using build libc and any other libs that are already on my embedded device (as well as any others that my executable will need to run in order to deploy on the device). In this way I am hoping to have all of the libs on my dev machine correctly linked with the appropriate version of libc.
My question is this - I know that the libc on the embedded device is 4.3.2 but how important is it that I use the same version of GCC to build the libraries locally on my dev machine?? Are there any potential complications if I actually use a more recent version (i.e. the one that came with my dev machine install which is 4.6.3) to build these libs??
As long as the ABI has not changed between compiler versions, you should be fine. From the back of my head, the C ABI hasn't changed in ages, and the C++ ABI not since 3.4 / 4.0. Check the official docs to be sure.
I have applications which successfully compile with the -m32 switch (in DMD and/or GCC) to produce:
appname: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.15, not stripped
The source packages I have created work fine, on both 32 bit and 64 bit Ubuntu to build the appropriate binary .debs.
I would like to produce the i386 .deb on the same 64 bit machine i use to produce the 64 bit .deb.
Is this possible, and where should I look for instructions?
The answer depends on the complexity of your build. When the normal 64 bit userland tools suffice for a build, simply specify the architecture via -a
debuild -ai386
However, there are often cases where this doesn't work, and in these cases you'll need pbuilder. pbuilder builds a clean Debian/Ubuntu system in a chroot-ed environment. man pbuilder is a good introduction. To get started, you'll need:
sudo pbuilder --create --architecture i386
sudo pbuilder --build mypackage.dsc
It starts with calling debuild with the -ai386 option, which will
change the architecture that the package is built for.
Of course you have to ensure that the package contains the i386 build of the application.
You don't do anything thing different from building a 64bit .deb. Except that you include a 32bit build of your application.
The control file specifies the architecture, so be sure you select the correct one.
I have some old hardware with an old version of say SuSE linux running on it. Now I have this fancy development machine running Ubuntu 9.10. Some of the tools I use to compile my C app (written in Python 2.6.x) are not available on the old SuSe box. So... is it possible to compile for that old machine on my dev box?
I have the following steps in mind, but would like to cross-check before venturing off into this quest:
1. Find out which static/shared libs my app needs and find/build target version of them
2. Also find the corresponding header files
3. Feed the correct flags to gcc to use the target headers and libraries
4. Feed the correct flags to gcc to use the correct architecture (i386/i686), or do I need a cross-compilation toolchain.
5. Compile, upload and enjoy ;-)
I regularly use avr-gcc and cc65, both are cross compiling. I know that you set up a coss compiler for developing something like a gumstix, so it should be possible to do the same for old/other Linux distros, not?
C
The way I would approach this is grab your oldmachine:/usr/lib and oldmachine:/usr/include so you have e.g. newmachine:/oldmachinecompiler/usr/{lib|include} then build a cross compiler setting --sysroot to newmachine:/oldmachinecompiler/
This is really the only way to ensure that any library requirements (including libc) in your program are compatible with oldmachine.