GDB test fails on SLAC psbuild machine

[ZLLentz]

Expected Behavior

Tests should have parity on the TravisCI and when run locally at LCLS.

Current Behavior

The gdb test fails when run on psbuild-rhel7, see https://github.com/pcdshub/pcds-envs/issues/253

Details

________________________________ test_gdb_info _________________________________

    @platform_skip
    @gdb_unavailable_skip
    @softioc_unavailable_skip
    def test_gdb_info():
        md = IocMetadata(binary=str(softioc))

        async def inner() -> Optional[GdbBinaryInfo]:
            return await md.get_binary_information()

        loop = asyncio.get_event_loop()
        info = loop.run_until_complete(inner())

        assert info is not None, "Script appears to have failed"
        print("Got information", info)

>       assert len(md.variables)
E       AssertionError: assert 0
E        +  where 0 = len({})
E        +    where {} = IocMetadata(name='unset', script=PosixPath('.'), startup_directory=PosixPath('.'), host=None, port=None, binary='/reg/...egisterRecordDeviceDriver.cpp': '8c8fa6c8de3f0f6bdbf9bb227c678070f5311606e7b8e9899b8932c3564a7f32'}, load_success=True).variables

whatrecord/tests/test_gdb_integration.py:47: AssertionError

Possible Solution

Idk, it might be a server configuration issue

Steps to Reproduce (for bugs)

1. Run the suite on psbuild-rhel7

Context

This adds some noise to the pcds-envs unit testing suite.

Your Environment

pcds-5.5.0

[klauer]

There is another semi-related failure in pcds-5.5.1-dev.

The static symbol pVersionCAC which whatrecord uses to determine the binary version is not present in the conda-forge epics-base softIoc executable, as it's instead part of the bundled shared library libca.so:

(pcds-5.5.1-dev) $ gdb epics/lib/linux-x86_64/libca.so.4.13.8
(gdb) p pVersionCAC
$1 = "@(#) EPICS 7.0.5, CA Client Library"

The test suite makes too many PCDS-specific assumptions about the environment to be useful.
Additionally, most facilities (outside of SLAC!) use dynamic linking for their EPICS binaries.
The tool may need to be extended to better support dynamic linking - which may make it a bit too complicated:

1. Running a softIoc binary just to have it load shared libraries (i.e., break main; continue; p pVersionCAC) even just to main seems bad and a bit error-prone
2. It could rely on ldd (on Linux, at least) to match the libca shared library and get info with gdb from there (this also seems complicated and error-prone)

I'd say for now:

1. xfail gdb tests
2. Keep assuming statically-built softIoc for our own purposes
3. If anyone shows interest in the tool from a facility that uses dynamic linking, re-evaluate at that point