Consider the following session:
...
$ podman pull docker.io/opensuse/leap
$ podman run -dt --pid host docker.io/opensuse/leap
<container-id>
$ podman attach <container-id>
...
and:
...
$ podman exec -it <container-id> bash
...
to get two shells.

Install emacs, gcc, gdb, sysvinit-tools using "zypper install".

Create a symlink /lib64-symlink -> /lib64.

Edit /etc/zypp/repos.d to enable debug repositories (open files with debug in name, replace 0 by 1 in enabled=0 line).

Install glibc-debuginfo.

Create test.c:
...
#include <unistd.h>
#include <stdio.h>

static volatile int hello = 0;

int
main (void)
{
  while (1)
    {
      sleep (1);
      if (hello)
	printf ("hello");
    }

  return 0;
}
...

And compile it:
...
$ gcc test.c -g -Wl,-rpath,/lib64-symlink
...

Run it in one shell, and find the pid and attach (using system gdb) in another:
...
$ gdb -iex "set debug separate-debug-file on" -p $(pidof a.out)
  ...
Looking for separate debug info (build-id) for /lib64-symlink/libc.so.6
  Trying /usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug... yes!
Reading symbols from /usr/lib/debug/lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
...

Note that gdb manages to follow the symlink of the .build-id file.

Likewise, if we move .build-id to .id-build, we get instead:
...
Looking for separate debug info (debug link) for /lib64-symlink/libc.so.6
  Trying /lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open.
  Trying /lib64/.debug/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open.
  Trying /usr/lib/debug//lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug... yes!
Reading symbols from /usr/lib/debug//lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
...

Note that again gdb manages to follow a symlink.

Now try from outside the container (using current gdb build from source) and sudo (and re-enable .build-id):
...
Looking for separate debug info (build-id) for target:/lib64-symlink/libc.so.6
  Trying /usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug... no, unable to compute real path
  Trying target:/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug... yes!
Reading symbols from target:/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug...
...

Note that in this case, we didn't follow the symlink.  That is not a problem, the file system handling follows the symlink and the file is found.

Again, move .build-id to .id-build:
...
Looking for separate debug info (debug link) for target:/lib64-symlink/libc.so.6
  Trying target:/lib64-symlink/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open.
  Trying target:/lib64-symlink/.debug/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open.
  Trying target:/usr/lib/debug//lib64-symlink/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open.
  Trying target:/usr/lib/debug/lib64-symlink//libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open.
(No debugging symbols found in target:/lib64-symlink/libc.so.6)
...

Note that in this case again, we didn't follow the symlink, but this time resulting in not finding the debuginfo file.