The Linux already having both gcc & arm-gcc in the environment path: So I configure the gdb 6.6: compiled without error, but looks like gdb used the wrong compiler. So How to indicate the correct CC for gdb? I tried make CC=arm-none-linux-gnueabi-gcc, but will get the error: Answer Don’t use –target. It means something else to Autotools. Use –build and
Tag: gdb
How to make gdb for a target and use it there
I am trying to compile gdb-8.2 from source. Build machine: x86-64 Host AND target: arm-linux-gnueabi I ran: Then I ran: So I got a usr folder inside gdb_installation folder. I copied the usr/local/bin/gdb to my target and ran Output: But it does not show anything. It exits without any message. What am I missing here? Running the file command shows
Cannot load custom ELF executable in GDB
I am currently writing a compiler (http://curly-lang.org if you’re curious), and have been encountering a strange bug when trying to run the generated ELF binaries on the latest Linux kernel. The same binaries run fine on older kernels (I’ve tried on several Ubuntu boxes, uname 4.4.0-1049-aws), but on my updated Arch box (uname 4.17.11-arch1), I can’t even open them under
ARM GDB cannot access memory only on Linux
Trying to switch development to Linux, but running into a (probably simple newbie) problem. On my Mac, I can use ARM GDB (arm-eabi-none-gdb from the GNU ARM Embedded Toolchain) to load my elf to my STM32L432, then at my breakpoints a simple i lo (or examine, or whatever) gives me the local vars. On Linux, however, the exact same code
C code to access environment variables
I created an environment variable SHELLCODE which contains a 200-byte long NOP sled and a shellcode. It is stored at 0x7fffffffe285, but I’ll try to access 0x7fffffffe2e5, which is around the middle of the NOP sled. Then I wrote the following code to try to access the variable. I used gdb to see the memory The pointer was clearly pointing
Weird behavior in GDB when defaulting copy/move constructors
I have the following code which seems to behave weirdly in GDB depending if the copy/move constructors are defaulted or not. I fire up GDB, add a breakpoint on the last cout in main and run “p t.get()” and I expect it to be 42 but depending on the value of the macro CUSTOM I get either 42 (when CUSTOM
Cannot insert breakpoints. Addresses with low values
I’m trying to debug this simple C program: But when I disassemble the main function I get this: And this is already pretty strange because addresses starts with a prefix of 4… for 32 bit executables and 8… for 64 bit executables I think. But going on I then put a breakpoint: I run it and I get this error
GDB: breakpoint in linux built-in module fails
I am debugging linux kernel using two virtual machines connected via serial port. Target machine awaits connection from remote gdb, by inserting kgdbwait() and kgdboc=ttyS0,115200 in the correct entry in /boot/grub/grub.cfg. In Host machine Symbols are read and I am supposed to be able to put breakpoints on function names. Works fine! However, if I set a breakpoint at htb_dequeue_tree
Why gdb backtrace syscall address is different from syscall table address
I’m really confusing with syscall address. 1 now I hook a syscall(fake_sendto) replace real syscall(sct[__NR_sendto]), and it workes normally. now I dmesg to show logs: ok, I think the truely sys_sento address is above 0xffffffff8156b2c0 but when I write a test program, gdb print sendto function address is 0x7ffff7b11400 ! see below gdb debug info: why does gdb show different
Know who is the inheritor while debugging core dumps with GDB
My process has crashed, and I have a core dump. I see that the process crashed while running a code similar to that : I have a full call stack in the core dump, but I don’t know who is the inheritor that runs the “func”. Is there a way to figure it out (maybe by some pointer calculation tricks