Re: Debugging containerized glibc tests with gdb (a developer use case for outside-of-container debugging).
Carlos O'Donell <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 12/27/19 12:55 PM, Gabriel F. T. Gomes wrote: > Hi, Carlos, > > On Fri, 27 Dec 2019, Carlos O'Donell wrote: >> >> Did you try --enable-hardcoded-path-in-tests? > > I hadn't. ¬¬ > That was it. Interesting! Thank you for looking into this more deeply. Reproducing these issues is half the battle! > You wrote this in your first email: > >> In test-container.c we mount $srcdir and $objdir into the same absolute paths >> inside the container, so ld.so should be accessible from the same absolute paths. >> If we fail those mounts we immediately fail the test with FAIL_EXIT1. > > I think the paths are the same, but the contents are not identical. On > the tests I did, the testroot.root/path/to/build/dir/elf directory is > missing the symlink between ld.so and ld<whatever>.so.<n>. For instance: Are you saying the contents of $objdir's mount in the sysroot are not the same as the contents of $objdir as seen _outsite_ of the sysroot? We have two paths: - Normal $objdir - $objdir as seen from within the sysroot's mount > $ ls -l testroot.root/home/gabriel/build/x86_64/glibc/elf > -rwxrwxr-x 1 gabriel gabriel 1342800 Dec 27 11:09 ld-linux-x86-64.so.2 A normal $objdir should have: lrwxrwxrwx. 1 carlos carlos 5 Aug 1 00:51 ld-linux-x86-64.so.2 -> ld.so -rwxrwxr-x. 1 carlos carlos 1458696 Aug 1 00:51 ld.so > $ ls -l testroot.root/home/gabriel/build/powerpc64le/glibc/elf/ > -rwxr-xr-x 1 gabriel gabriel 1566232 Dec 27 09:05 ld64.so.2 Likewise. > Whereas on the actual build dir: > $ ls -l elf/ld*.so* > lrwxrwxrwx 1 gabriel gabriel 5 Dec 27 09:04 elf/ld64.so.2 -> ld.so > -rwxr-xr-x 1 gabriel gabriel 1566232 Dec 27 09:04 elf/ld.so Yes, this is correct. >> warning: Could not load shared library symbols for /home/carlos/build/glibc-gr-localedef/elf/ld.so. > > If I create the ld.so symlink in the sysroot, the problem goes away. > Should there be a symlink in the sysroot? Why would we need to create it? I thought this path was simply a MS_BIND mount of the $objdir and should have identical contents? -- Cheers, Carlos.