Sometimes with debugging on Linux, the noisy symbol messages you see aren't necessarily the "final result". Before any plug-in (e.g.: the ELFBinComposition.dll Linux/ELF/DWARF plug-in) gets a chance to take over binary/symbol loading, the debugger will go down the default path that it takes with Windows/PE/PDB and will fail (resulting in some error messages).

What does lmvm show for these binaries? I'm surprised we'd fail to find the binary & symbols for a released .NET libcoreclr. I'm a bit less surprised on the Ubuntu distro libc.

If you want to get symbols, the debugger requires BOTH the executable AND the debug package (though depending on circumstances that might be a single ELF). We don't look for the debug package if we can't find the executable. I've certainly seen some of the DebugInfoD servers (including for some Ubuntu releases) that will serve up the debug package but will NOT serve up the executable. That's fine if you're using DebugInfoD on the box in question (where the binary is on disk). It's much less fine if you're trying to analyze the dump file on a separate machine that doesn't have those files on disk (which is always the story with WinDbg).

When I'm personally analyzing core dumps I've taken from my Linux VMs that are for distros I know don't always have binaries & symbols indexed reliably, I'll copy some of the binaries I care about out of the VM along with the core dump.

I also suspect that your "rebuilding" glibc is not an identical binary. The build processes will typically embed a 160-bit SHA-1 hash as the "build-id" in the first page of an ELF binary (typically right after the program headers in an ELF note). The core filters are typically configured so that a core dump captures the first page of any mapped ELF in order to capture that ID. The debugger will not, by default, load any binary/symbols that do not have matching build-ids (much like we do for PE/PDB on the timestamp & image-size or RSDS GUID). You can, of course, override that by setting SYMOPT_LOAD_ANYTHING (with the .symopt+ command). That's not recommended unlesss you really know what you are doing since it will allow mismatched binaries & symbols to load and can result in a very poor debug experience.