t/porting/libperl.t: fix issue with common symbols

[iabyn]

Test 5 was failing on newer Linux builds with clang and ASAN.

This was indirectly because although since around 2020 both gcc and clang have -fno-common by default, clang+ASAN was putting some private symbols in the common section of the libperl object file while under -fno-cpmmon, namely this output from nm:

0000000000000008 C ___asan_globals_registered

It so happens that libperl.t handled -fno-common by aliasing a hash, $symbols{data}{common}{}, to another hash, $symbols{data}{bss}{} if {common} was empty. It then looked up a particular symbol under {common} and found it even if it was actually under {bss}. This scheme failed as soon as {common} was non-empty even under -fno-common.

This commit removes the common-to-bss aliasing trick and instead looks for the symbol under both common and bss. The test passes if either is found.

This commit also changes the test diagnostic output accordingly. It also now recognises (but ignores) 'w' and 'W' weak symbol types in nm output, such as

                 w __stop_asan_globals

TODO: fill description here

---

• This set of changes requires a perldelta entry, and it is included.
• This set of changes requires a perldelta entry, and I need help writing it.
• This set of changes does not require a perldelta entry.

[jkeenan]

Test 5 was failing on newer Linux builds with clang and ASAN.

Can you provide the Configure invocation that reproduces this? Thanks.

[iabyn]

On Wed, Sep 11, 2024 at 12:13:45PM -0700, James E Keenan wrote: > Test 5 was failing on newer Linux builds with clang and ASAN. > Can you provide the Configure invocation that reproduces this? Thanks.

The standard clang+ASAN:

…

-Accflags=-fsanitize=address -Aldflags=-fsanitize=address -Dcc=clang

-- Never do today what you can put off till tomorrow.

[Leont]

This test keeps being a continuous source of breakage, seems like every major release has at least one. At the same time its benefit is kind of dubious, has it ever even caught an issue?

I'm not sure we should keep this test, it seems like a poor trade-off.

[iabyn]

On Thu, Sep 12, 2024 at 01:06:52PM -0700, Leon Timmermans wrote: This test keeps being a continuous source of breakage, seems like every major release has at least one. At the same time its benefit is kind of dubious, has it ever even caught an issue? I'm not sure we should keep this test, it seems like a poor trade-off.

Looking at the commit which added it, it made more sense back then as it was testing where usual text and data symbols ended up on normal vs DPERL_GLOBAL_STRUCT vs DPERL_GLOBAL_STRUCT_PRIVATE builds. Now that those two configuration options have been removed, it doesn't seem very useful. So I lean towards getting rid of it.

…

-- "Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit." -- Lady Croom, "Arcadia"