2

I'm running a Linux container via Docker on a MacBook M1 running Tahoe (macOS 26.0.1). Following the appendix for setting up GDB in the back of the book I'm using, I start by typing in GDB on the command line. Then when the GDB prompt comes up, I do file foo which is my executable file that I'm hoping to step through. The author says to then add a breakpoint to the entry point of the program, which I do with break *_start. All good so far. After that it's just a simple matter of typing run and we're good to go. It should "immediately stop and let me know that the debugging hit the breakpoint that I added." Except that when I enter run, I get this error message:

Starting program: /my-code/programs/tallest/longestname 
warning: Error disabling address space randomization: Operation not permitted
Couldn't get registers: Input/output error.
Couldn't get registers: Input/output error.

If I try to run the program again it will tell me that the program is already running, and do I want to start it again. But all core functionality of the debugger is unavailable. If I try to do disassemble or info registers it just tells me Couldn't get registers: Input/output error. again.

The file in question has full permissions for the owner (-rwxr) and so that doesn't seem to be the problem, and I can't figure out what is.

Improve this question
5
  • 2
    Does this help at all: stackoverflow.com/questions/42029834/… Commented Oct 22 at 10:24
  • No but thanks. Can't seem to find an answer anywhere. Commented Oct 23 at 4:25
  • I'm sorry -- I didn't look closely enough. While the input/output errors remain (and they are the ones keeping me from being able to use the debugger), the solution you linked to does at least get rid of this error: warning: Error disabling address space randomization: Operation not permitted. So that's something, at least. Appreciate your taking the time to reply. Unfortunately, these input/output errors are still there, and one comes up every time I try to check the values of the registers or disassemble the executable to generate object code. No idea what to do next. Commented Oct 24 at 20:26
  • 2
    Are you running an Aarch64 container? Or are you emulating x86-64? If the second, then have a read through: github.com/docker/for-mac/issues/6921 and see if that helps at all. Commented Oct 25 at 9:11
  • You found it! This is my problem, for sure (and yeah, running a container for x86_64). So many workarounds and possible solutions here. If the answer isn't here, then there isn't one. I'll post an answer when I'm able to get it working, or report back here otherwise, just so the thread has a resolution for anyone in the future with the same problem. Anyways, thank you very much. Really appreciate your digging that up. Gratitude. Commented Oct 25 at 16:40

1 Answer 1

Reset to default
1

So, after a whole lot of research, tinkering, and help from the good people here at SO and elsewhere, I've found a workaround for this problem (or, really, I should say, it was found for me). Not a true fix, just a workaround. I'll post it here for future reference.

The first of the errors listed above -- this one:

warning: Error disabling address space randomization: Operation not permitted

can be dealt with simply, by adding these options --cap-add=SYS_PTRACE --security-opt seccomp=unconfined to your Docker run commmand. For me the whole thing looked like this:

docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -it --rm 
--mount "type=bind,src=`pwd`,target=/my-code" container_name_here

This still leaves, however, the following error:

Couldn't get registers: Input/output error.

This is the difficult one. The workaround, which was found on a github discussion page linked to by a wonderful commenter on this page, goes like this: Once you're in your container, instead of simply typing gdb to start up the debugger, enter:

ROSETTA_DEBUGSERVER_PORT=1234 ./file_name & gdb

(file_name here is just the file you're trying to debug.)

Then, once the GDB prompt comes up, execute the following three commands:

(gdb) set architecture i386:x86-64
(gdb) file file_name
(gdb) target remote localhost:1234

For myself and apparently many others, this has worked as a solution -- at least to get some of the basic funcitonality of the debugger to work (e.g. dissassemble and info registers). It is not an ideal solution, and there's really no reason it should be necessary (that I know of). But, then, I know very little about all this, certainly not nearly enough to know why this input/output error seems to be plaguing everyone who tries to use GDB within an x86-64/AMD64 container or what the chances are that the problem may be fixed in the future, and I haven't heard from anyone who's been able to shed any light on why it's happening in the first place. Still, I hope this is helpful.

Thanks to everyone who helped. All the best.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

because you confirm that the approach with environment variable is working, i wonder if you could also just do "export ROSETTA_DEBUGSERVER_PORT=1234" first in isolation (on a line by itself). then gdb (by itself), then in gdb do set env ROSETTA_DEBUGSERVER_PORT=1234 then file file_name and then the program will "wait" and you can hit main (if needed) by using break main and then run in gdb. because the original posted solution launches file_name before launching gdb. you may be able to invert that.
otherwise, it seems the script posted further down on that github issue is even better: github.com/docker/for-mac/issues/6921#issuecomment-2409324575

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.