I want to read data from a file in assembly AT&T but I don't really know where to start.
I haven't found a useful resource on internet.
My working environment info:
OS: Ubuntu 14 - 64 bit
CPU: Intel
GAS compiler
Assembly Sintax: AT&T
I'll assemble with: as -o hello.o hello.s
I'll link with: ld -o test hello.o
Look up how to do systems programming on POSIX in C (open/read/write/etc.), then use the same system calls in your asm. There's nothing special about asm for this, compared to just doing it in C. (except that in C you'd be using the glibc wrappers instead of the syscall instruction directly.)
See the x86 tag wiki for links documenting how to make system calls from asm.
Related
I need to build a complete linux development framework for a Cortex-M MCU, specifically a STM32F7 Cortex-M7. First I've to explain some background info so please bear with me.
I've downloaded and built a gcc toolchain with croostool-ng 1.24 specifying an armv7e-m architecture with thumb-only instructions and linux 4.20 as the OS and that I want the output to be FLAT executables (I assumed it will mean bFLT).
Then I proceeded to compile the linux kernel (version 4.20) using configs/stm32_defconf, and then a statically compiled busybox rootfs, all using my new toolchain.
Kernel booted just fine but throw me an error and kernel painc with the following message:
Starting init: /sbin/init exists but couldn't execute it (error -8)
and
request_module: modprobe binfmt-464c cannot be processed, kmod busy with 50 threads
The interesting part is the last message. My busybox excutable turned out to be an .ELF! Cortex-M has no MMU, so it's imposible to build a linux kernel on a MMU-less architecture with .ELF support, that's why an (464c)"LF" binary loader can't be found, there is none.
So at last, my question is:
how could I build bFLT executables to run on MMU-less Linux architectures? My toolchain has elf2flt, but in crosstool-ng I've already specified a MMU-less architecture and FLAT binary and I was expecting direct bFLT output, not a "useless" executable. Is that even possible?
Or better: is there anywhere a documented standard procedure to build a complete, working Linux system based on Cortex-M?
Follow-up:
I gave up on building FLAT binaries and tried FDPIC executables. Another dead end. AFAIK:
Linux has long been supporting ELF FDPIC, but the ABI for ARM is pretty new.
It seems that still at this day and age, GCC has not a standard way to enable FDPIC. On some architectures you can use -mfdpic. Not on arm, don't know why. I even don't know if ARM FDPIC is supported at all by mainline GCC. Info is extremely scarce if inexistent.
It seems crosstool-ng 1.24 is BROKEN at building ARM ELF FDPIC support. Resulting gcc has not -mfdpic, and -fPIC generates ARM executables, not ARM FDPIC.
Any insight will be very appreciated.
you can generate FDPIC ELF files just with a prebuilt arm-linux-gnueabi-gcc compiler.
Specifications of an FDPIC ELF file:
Position independent executable/code (i.e. -fPIE and fPIC)
Should be compiled as a shared executable (ET_DYN ELF) to be position independent
use these flags to compile your programs:
arm-linux-gnueabi-gcc -shared -fPIE -fPIC <YOUR PROGRAM.C> -o <OUTPUT FILE>
I've compiled busybox successfully for STM32H7 with this method.
As I know, unfortunately FDPIC ELFs should be compiled with - shared flag so, they use shared libraries and cannot be compiled as -static ELF.
For more information take a look at this file:
https://github.com/torvalds/linux/blob/master/fs/binfmt_elf_fdpic.c
Track the crosstool-ng BFLAT issue from here:
https://github.com/crosstool-ng/crosstool-ng/issues/1399
Can someone explain the difference between the three architectures?
Actually when I built a 64-bit application in Linux, I got a link error saying:
skipping incompatible library.a when searching for library.a
Then I used objdump -f on that library and I got the below output:
a.o: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
Does it mean the library is 32-bit? Is that the reason I am getting the linker error?
There are 3 common ABIs usable on standard Intel-compatible machines (not Itanium).
The classic 32-bit architecture, often called "x86" for short, which has triples like i[3-6]86-linux-gnu. Registers and pointers are both 32 bits.
The 64-bit extension originally from AMD, often called "amd64" for short, which has GNU triple of x86_64-linux-gnu. Registers and pointers are both 64 bits.
The new "x32" ABI, with a triple of x86_64-linux-gnux32. Registers are 64 bits, but pointers are only 32 bits, saving a lot of memory in pointer-heavy workflows. It also ensures all the other 64-bit only processor features are available.
Each of the above has its on system call interface, own ld.so, own complete set of libraries, etc. But it is possible to run all 3 on the same kernel.
On Linux, their loaders are:
% objdump -f /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2
/lib/ld-linux.so.2: file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000a90
/lib64/ld-linux-x86-64.so.2: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000000c90
/libx32/ld-linux-x32.so.2: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000960
Now, if you're getting the message about "skipping incompatible library", that means something is messed up with your configuration. Make sure you don't have bad variables in the environment or passed on the command line, or files installed outside of your package manager's control.
Beyond usual full 64bit and good old 32bit ABI there is a special ABI (inspired by SGI n32 envirnment) where pointers are 32bit (thus they are 32bit apps), but it is designed to run on 64bit host and have full access to all x64 goodies:
native x64 registers and math
more registers
SSE2/3/4, AVX1/2/...
Full 4Gb address space on 64bit host
It is called x32 ABI, link: https://en.wikipedia.org/wiki/X32_ABI
UPDATE
On Ubuntu system I have to install two packages (with deps) to get x32 working:
> sudo apt install gcc-multilib
> sudo apt install libx32stdc++-5-dev
Then compiling simlple C++ code with g++ -mx32 hellow.cpp works, making x32 executable
> file a.out
./a.out: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0
I am porting a Windows VC++ application to Linux that links to an assembler module currently produced by MASM. After changing its Windows ABI assumptions to Linux ABI, I would like to again assemble the module on MASM to OMF (in Windows), then directly input that object file into the GCC build (in Linux). This would greatly simplify maintenance over time and guarantee an identical assembly under both operating systems. The alternative is porting the assembler code to YASM/NASM and its complications. The assembler code is entirely leaf routines (no calls), with no macros, no Unicode data and scant integer/real data; it includes 32-bit and a 64-bit assembler versions. Barring endian issues, does it really matter whose tool chain generates the OMF representation for this module?
I tested out it out using a simple test case and it worked fine when linked using the GNU linker under Linux. So you probably don't need to do anything special.
Here's the assembly file I tested it with:
_TEXT SEGMENT USE32
PUBLIC foo
foo:
mov eax, 1234
ret
_TEXT ENDS
END
And here's the C program:
#include <stdio.h>
extern int foo();
int
main() {
printf("%d\n", foo());
return 0;
}
I assembled the first file on Windows using MASM, copied the resulting .OBJ file to a Linux machine (Debian x86_64) and compiled/linked it with the following command:
gcc -m32 main.c foo.obj
Running the generated executable (a.out) produced the expected output: 1234. I also tested the equivalent 64-bit case and it worked as well.
Unless you're dependent on PECOFF-specific section (segment) ordering or other PECOFF-specific features it looks like you shouldn't have any problems, at least far the object file format goes. Note it's possible that the version of the GNU linker installed on your Linux machine wasn't built with support for PECOFF. In that case you may need to build your own version from source.
Trying to learn NASM Assembly. I have a 64-bit machine, with Ubuntu. Recently I decided to test the push and pop instructions. I do this:
nasm -felf64 Test.asm
Apparently they are not supported in 64-bit mode. Alright, no problem, I'll just do it for 32 then:
nasm -felf Test.asm
And now, as always,
gcc Test.o
But it now tells me
i386 architecture of input file 'Test.o' is incompatible with i386:x86-64 output
I don't quite grasp the error here. How can I test push and pop in my 64-bit machine, if apparently I can't compile 32-bit programs?
How about "-m32"?
And I think you need to care dependent library(e.g libc), see: Use 32bit shared library from 64bit application?
First, you can use push and pop in 64-bit code, just not with 32-bit registers. If you push and pop 64-bit registers, it'll work fine. In most cases, you can use 32-bit registers in 64-bit code, just not push and pop. There may be other exceptions, but I'm not aware of 'em.
64-bit code uses different system call numbers, puts the parameters in different registers, and uses syscall instead of int 0x80. However, the old int 0x80 interface with the old system call numbers and parameters in the old registers still works. This gives you kind of "mixed" code and may not be a Good Idea, but it works. How long it will continue to work in future kernels is anybody's guess. You may be better off to learn "proper" 64-bit code.
But there are (still!) a lot more 32-bit examples out there. You can tell Nasm -f elf32 (just -f elf is an alias, but I'd use the "full name" just for clarity). If you're using gcc, tell it -m32. If you're using ld directly, tell it -m elf_i386. You do have choices, but they have to be compatible with each other.
how about the "-march=i386" ? see:
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
I have a project with one .c C source code and one .S assembly source code. Once compiled and linked, is there any way to debug .S code using Kdbg? I am calling one .S function from .c file but no code loads in Kdbg.
Add a .file directive in your source, like: .file "sourceasm.s". Kdbg will then use it as expected.
I I just tried kdbg (the KDE front-end for gdb, not the Linux kernel debugger kgdb of almost the same name).
It doesn't seem to have a proper disassembly mode like regular gdb's layout asm. You can set the "memory" window to disassembly and the address to $pc (and it updates as you single step), but that ties up the memory window and isn't very flexible for setting breakpoints or scrolling backwards to instructions before the current RIP/EIP.
Even if you're debugging asm source, you sometimes want to have the debugger show you the real disassembly, as well / instead of the asm source. For example in code that uses macros, or NASM %rep to repeat blocks.
AFAICT, kdbg is not a very good choice for asm debugging. text-mode GDB with layout asm / layout reg is ok; see the bottom of the x86 tag wiki for tips. I've also tried https://github.com/cs01/gdbgui. It has a disassembly mode, but it's not very nice.
As #ivan says, kgdb will let you do source level debugging of asm source files if you add enough metadata for it to know what source file the object came from.
gcc: Build with gcc -g foo.S
NASM: Assemble with nasm -felf64 -g -Fdwarf to include DWARF debug info. (The NASM default is STABS debug info, which also works.)
YASM: Assemble with yasm -felf64 -gdwarf2.
See Assembling 32-bit binaries on a 64-bit system (GNU toolchain) for more about building static / dynamic binaries from asm source.