'info proc' doesn't work on replays

[jrmuizel]

(rr) info proc process 5331 warning: unable to open /proc file '/proc/5331/cmdline' warning: unable to read link '/proc/5331/cwd' warning: unable to read link '/proc/5331/exe'

I'm not sure if 'info proc' is supposed to work with remote targets, if not I guess gdb needs to be improved.

The reason I was interested in this was to get a list of mappings of the replayed process so that I could search the target's memory.

[rocallahan]

info proc doesn't give direct access to /proc/.../maps AFAICT.

We might be able to get some of info proc to work by implementing the vFile protocol, which apparently gdb tries to use. However, I don't think this would help you.

You can use when-tid to get the real process ID and then /proc/.../maps will give you the mappings for the replayed process, with some weird names but it should be OK for your purposes.

The gdb find command is implemented in rr over the remote protocol so that should work well.

[rocallahan]

oh, I see info proc mappings now.

When I run that under rr with RR_LOG=GdbConnection I see only one remote request being made, a readlink on /proc/.../cwd :-(.

[rocallahan]

The other thing we could do is override info proc mappings completely to dump some data direct from rr.

[GitMensch]

info proc mappings works fine, but the other parts of info proc, also requested in #1834, does not.

I've just rechecked: using "plain gdbserver + gdb" this works fine, a way to have this working in rr would be:

• record output of:
  • /proc/$pid/cmdline
  • /proc/$pid/cwd
  • /proc/$pid/exe
• interrupt the calls from GDB requesting those (the remote GDB shows those from the inferior, so has to ask gdbserver for that)

If for some reason those cannot be intercepted, then a new command rr-info proc could show them.