SignalsTest.PrintsSymbolizerMarkup relies on --build-id at link time

[jrtc27]

In order to get the module: and mmap: lines from DSOMarkupPrinter::printDSOMarkup, there must be an NT_GNU_BUILD_ID note in the binary. However, this is not something that is guaranteed, as different platforms have different defaults, and even within that you can configure it (e.g. ENABLE_LINKER_BUILD_ID in the case of Clang). This test is therefore very fragile (e.g. it breaks on FreeBSD when built with Clang+LLD, as (a) ENABLE_LINKER_BUILD_ID defaults to OFF (b) there is no code in FreeBSD.cpp to pass --build-id if ENABLE_LINKER_BUILD_ID is set (c) LLD defaults to no build ID if no option is passed) and I believe should be disabled or marked flaky somehow until it's able to accurately capture the requirements from its environments.

Cc @mysterymath as the author of the test (in 8d3ff60).

[jrtc27]

Note that Debian's LLVM packaging sets ENABLE_LINKER_BUILD_ID to ON, for example, and I suspect other distros do as well given build IDs are useful, especially with things like debuginfod, so it's unsurprising this issue has gone unnoticed. Similarly Debian's GCC passes --build-id by default (I've not checked if this is an upstream default or a distro-specific configuration).

[mysterymath]

I think it's totally fair to disable this one under this issue. I'd wager there's a way to bail from the test if it detects at runtime that the running binary cannot obtain a non-zero build ID for itself; I think that's just about the only way to repair it without rethinking the test approach entirely. But that'll take a bit of time, so in the meantime, feel free to swing the disable-hammer.

[jrtc27]

Thanks for the quick response; #168974 posted for review to do just that