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.
Related
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.
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.
How do I dump debug_loc section from an executable on Linux if default options (-g) are provided to GCC while compiling a C file? I use readelf linux utility.
GCC by default produces DWARF info in DWARF4 format, so if I pass -g-dwarf2 I can see .debug_loc section but how do inspect that section if info is generated with default options as I don't see the section in dump?
Do you use a recent version of binutils? On Ubuntu 14.04 I can build executable with "gcc -g test.c -o test".
With "readelf --debug-dump=info test" I can confirm it's using DWARF 4.
After that, you have (at least) two ways to dump the contents of .debug_line section.
readelf --debug-dump=decodedline test
This will dump decoded line number information. You get line==address mappings directly.
There is also:
readelf --debug-dump=rawline test
This gets you raw debug_line contents.
Usually, .debug_loc is generated for optimized code. Try optimizing your code using compiler flags.
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 simple assembly program with the following makefile:
all : calc
calc : calc.o
gcc -m32 -g -o calc calc.o
calc.o : calc.s
nasm -f elf -g -F stabs calc.s
I try to debug it using gdb but it always says:
Single stepping until exit from function asc2int, which has no line number information.
I tried many solutions to the problem, including -F dwarf but none of them works. Can you please help me resolve this issue?
I don't see any problems with your makefile.
Quick google search gives following nasm. The documentation example shows you need to disassemble to look through the code, but its kind of weird, as already assembly code is being debugged why would the debugger ask to disassemble it further. However the disassembled code is inline with assembly source file.
Form what you have mentioned it seems you are able to debug. use nexti in case if you are using next instruction to step through. You can you disassemble command to every time see where the execution control lies. Or if you want it automated you can save following as a script. asm_next becomes the new instruction for you step in through the code.
set language asm
set disassembly-flavor intel
define asm_next
nexti
disassemble
end
Run it using the command
gdb -x <script> calc
P.S. for larger programs you might need to ad -O0 flag to get correlation between debugger disassembled code and your assembly code in .s file.