i#1840: Add helpful error if /proc is not mounted on Linux

[GandholiSarat]

Adds a Linux-only check during core initialization to verify that
/proc is mounted when running in managed mode. If not, DynamoRIO
emits a clear and actionable usage error instead of failing later
with a confusing loader error.

The check is guarded by !standalone_library so it applies to all
managed modes (injection, dr_app, attach/detach) while excluding
standalone/library-only usage such as drdecode.

Fixes #1840.

[GandholiSarat]

I’ve reverted the check to core and guarded it with !standalone_library, so it now runs only in managed modes (injection, dr_app, attach/detach) while excluding standalone/library-only usage such as drdecode.

With /proc unmounted, drrun now emits the intended error and exits cleanly. Since core in managed mode relies on /proc, this ensures all managed entry points provide the helpful message without impacting standalone use.

Please let me know if you’d prefer a different managed-mode boundary.

[GandholiSarat]

Since this is my first time , I wanted to ask about the testing approach.

To validate the /proc-missing scenario locally, I’ve been using:

sudo unshare -m -- sh -c '
  mount --make-rprivate /
  umount -l /proc 2>/dev/null || true
  ./build/bin64/drrun -- /bin/true
'

This lets me simulate a missing /proc using a separate mount namespace without affecting the host system.

Is this the recommended way to validate environment-dependent behavior like this, or is there a more idiomatic way within the DR test framework to exercise such scenarios?

I’m still learning the project conventions, so I’d appreciate any guidance.

[derekbruening]

Since this is my first time , I wanted to ask about the testing approach.

To validate the /proc-missing scenario locally, I’ve been using:

sudo unshare -m -- sh -c '
  mount --make-rprivate /
  umount -l /proc 2>/dev/null || true
  ./build/bin64/drrun -- /bin/true
'

This lets me simulate a missing /proc using a separate mount namespace without affecting the host system.

Is this the recommended way to validate environment-dependent behavior like this, or is there a more idiomatic way within the DR test framework to exercise such scenarios?

I’m still learning the project conventions, so I’d appreciate any guidance.

If you're asking whether to add a regression test: generally for new features or bug fixes it is best to add a test. For this check it feels less necessary and manual testing at commit time seems ok, but a regression test could be nice. If going the manual testing route it is good to describe in the description how it was tested.

If you're asking about using sudo in a regression test: we do have some existing sudo-requiring tests, and GA (Github Actions) VMs do allow that in batch mode. We mark such tests with a _SUDO suffix and have a cmake option RUN_SUDO_TESTS so they can be turned off to avoid annoying developers in setups where a hard to see password prompt in the middle of a set of tests is confusing.

If you're asking about using "unshare": I don't know myself if there's a better way; this would be specific to Linux but presumably would run on GA VMs. We don't have a lot of existing regression tests of this sort so there's not much precedence. I guess related tests would be trying to support various BSD flavors which I believe don't mount procfs nearly as readily but we don't have much effort in that direction.