1

EDIT Changed my code to just a hello world example, I've provided an object dump and read elf output. I tried building gdb version 13.1 from source but I'm still seeing the same behavior. This makes me believe it's an issue based on something gdb is using

OBJECT DUMP https://pastebin.com/sJNtWm6K

READELF -a OUTPUT https://pastebin.com/xynjJVPn

#include <stdio.h>

int main(int argsc, char* argv[])
{
  printf("Hello World\n");
  return 0;
}

OLD Question I'm trying to learn C++. I'm running the code on my Raspberry Pi 4 running Raspberry PI OS. I type these commands into the terminal.

g++ -g brainfuck.cpp -o brainfuck -O0
gdb brainfuck 
// inside of gdb
break main
Breakpoint 1 at 0xd74: file brainfuck.cpp, line 49.
run
// output of gdb
Starting program: /home/deca/Programming/Cpp/brainfuck 
Now SP is 3During startup program exited normally.

I check that gdb actual set my break point

(gdb) info breakpoint
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000000d74 in main(int, char**) at brainfuck.cpp:49

but for some reason it skips past it all the way to the end of my program. Does anyone know why this is happening? And is someone able to recreate this behavior on their PI 4 as well?

So far I've tried

  1. removing and redownloading gdb using the package manager
  2. using set breakpoint auto-hw off based on the suggestion of another user
  3. using the flags -O0 -g -ggdb -fno-omit-frame-pointer -gcolumn-info
  4. Creating a Hello World program and seeing if break points work there
  5. Running gdb as root as outlined in this stackoverflow post from 9 years ago
  6. Setting a breakpoint a _start with b _start
  7. Compiling a new version of GDB from source

The output of strace -f -o syscall.txt gdb ./helloworld on my hello world example

warning: Could not trace the inferior process.
warning: ptrace: Operation not permitted
During startup program exited with code 127.

Versions

g++ (Debian 10.2.1-6) 10.2.1 20210110

GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

Linux raspberrypi 5.15.84-v8+

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

NAME="Debian GNU/Linux"

VERSION_ID="11"

VERSION="11 (bullseye)"

decabytes
  • 386
  • 2
  • 14
  • 1
    I downloaded and built your program. I ran `gdb` and set the breakpoint on `main`. It stopped at the correct place. I'm unable to reproduce your problem. I'm using an x86 pc running linux. But, I've run `gdb` under an Rpi (under linux) in the past without any such problem (linux). `strace` and `gdb` both use `ptrace`, so I'm not surprised by the error (happens on my machine). You could test `gdb` at bit [more] with (e.g.) `list main`. Regardless of the body of `main`, the breakpoint should stop. You could try `b _start`, then `run` to see what happens (it's the absolute first inst to be run). – Craig Estey Mar 11 '23 at 02:16
  • 1
    One thing that looks suspicious is the address of `main`: `0x0000000000000d74`. This looks more like the _file_ offset of `main` in the executable. This can vary, but the address on my machine is: `0x000000000040121a`. I'd expect a similar relocation address for the RPi. Not sure where the Rpi puts things (so the low address _could_ be valid). You could also try: `disassemble main` or `disassemble _start`. Also, `readelf -a brainfuck` might help. Or, `objdump`. – Craig Estey Mar 11 '23 at 02:25
  • 1
    I'd be interested to know what the output of #4 and #6 were in the "things I've tried" list. I agree with Craig that your addresses look weird, `objdump` / `readelf` output would be interesting. You can also start GDB with `starti` which will stop at the very first instruction, whatever that is. Then you can try moving forward using `step`, `stepi`, `next`, `nexti`, etc from there to figure out what's going on. – Andrew Mar 11 '23 at 11:39

0 Answers0