Where are the debug symbols for libstdc++6?

If you look at https://launchpad.net/ubuntu/+source/gcc-10 and https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/binutils/+build/19150412 you will see that the two package mentioned by you do stem from the same build job.

Thanks Manfred, but I don't see what I'm looking for. I see no libstdc++*dbgsym.

Can you point me at the package which contains debug symbols for the release build of libstdc++?

There is no separate package with debug symbols for libstdc++.so.6, but a different copy of the shared library with debug information included.
see e.g. chapter "Versioned C++" in https://randomascii.wordpress.com/2013/01/08/symbols-on-linux-part-one-g-library-symbols/

I do not know what exactly you want to achieve, but one possibility to have libstdc++ debug information available for a program is
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6.0.28 ./myprogram

Hi Manfred, yes I understand what is in the libstdc++6-dbg packages. To make use of those I need to be running my program against those packages.

What I am looking for is a way to be able to get useful debug information in libstdc++ for programs which are running against the regular/production build of that library.

E.g.
1) System configured to allow me to get access to core files, rather than apport eating them.
$ cat /proc/sys/kernel/core_pattern
core-%e-%p

2) C++ program that breaks in libstdc++:
$ cat broken.cpp
#include <sstream>

int main ()
{
  std::ostringstream os;
  char *buffer = nullptr;
  os.write(buffer, 4096);
  return 0;
}

3) It crashes, leaves behind a core:
$ file core-broken-362553
core-broken-362553: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './broken', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: './broken', platform: 'x86_64'

4) Look at the core in gdb. No line numbers or function arguments in libstdc++:
(gdb) bt
#0 0x00007fda1c03e3b0 in std::basic_streambuf<char, std::char_traits<char> >::xsputn(char const*, long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007fda1c030357 in std::ostream::write(char const*, long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x0000563707d15220 in main () at broken.cpp:7

By comparison, if I am debugging a similar scenario on CentOS 7, gdb kindly tells me:
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.5.x86_64 libgcc-4.8.5-39.el7.x86_64 libstdc++-4.8.5-39.el7.x86_64

And once I have run that command, gdb gives me symbols in the backtrace, like:
(gdb) bt
#0 to_int_type (__c=@0x0: <error reading variable>) at /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/char_traits.h:285
#1 std::basic_streambuf<char, std::char_traits<char> >::xsputn (this=0x7ffffa3c5cf8, __s=0x0, __n=4096)
    at /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/streambuf.tcc:98
#2 0x00007f7089589402 in sputn (__n=4096, __s=0x0, this=<optimized out>) at /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/streambuf:451
#3 _M_write (__n=4096, __s=0x0, this=0x7ffffa3c5cf0) at /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:313
#4 std::ostream::write (this=0x7ffffa3c5cf0, __s=0x0, __n=4096) at /usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/ostream.tcc:196
#5 0x00000000004007b0 in main () at broken.cpp:7

No need to reproduce the crash against special debug builds of libraries.

It is unfortunate that Ubuntu does not support this method of debugging.

I searched the launchpad pages for gcc-10 and it seems to me that the files which you want, simply don't exist for Ubuntu focal.
For Ubuntu groovy the package libstdc++6-dbgsym does exist.

Suggestion:
There are PPAs with versions that include -dbgsym packages, see https://launchpad.net/ubuntu/+ppas?name_filter=gcc-10 for candidates.

https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1882502

Thanks Kai.

I can confirm these new packages solve the problem for the testcase I described in comment 4.

Sorry for the late reply.

Thanks Kai Kasurinen, that solved my question.