From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6D7083858C50; Fri, 12 Apr 2024 11:48:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6D7083858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712922531; bh=ftZtdyuLdyQf8lZ8LEvViLcLdKoX1Cj86W+AM6qdWuY=; h=From:To:Subject:Date:From; b=ZmLiVScyicXE89S5kv0kuKQxK4Nc8/K3Tn7/7OTm9mXPCUTV9dlvCVWnihZrTtOf/ +CRs8SXwKc70f2X8Gm6B2PFmAQrCZb0TJ/+r381nz/uQDlDJ6Xo8NKcjQUBiTE8WoV b8V0EzROgyOGC0Afnl8vmxjRTrftUSqr95zZ1ohs= From: "pablogsal at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug corefiles/31635] New: debuginfod cannot correctly fetch shared libraries without soname from server due to inconsistency Date: Fri, 12 Apr 2024 11:48:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: corefiles X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pablogsal at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31635 Bug ID: 31635 Summary: debuginfod cannot correctly fetch shared libraries without soname from server due to inconsistency Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: corefiles Assignee: unassigned at sourceware dot org Reporter: pablogsal at gmail dot com Target Milestone: --- When gdb uses debuginfod to fetch missing sharedlibraries from a given debuginfod server it fails for most libraries that don't have a soname due = to an inconsistency in how the buildids are registered and how they are querie= d. In corelow.c in the build_file_mappings we can see how the build ids are registered: /* If this is a bfd of a shared library, record its soname and build id. */ if (build_id !=3D nullptr) { gdb::unique_xmalloc_ptr soname =3D gdb_bfd_read_elf_soname (bfd->filename); if (soname !=3D nullptr) set_cbfd_soname_build_id (current_program_space->cbfd, soname.get (), build_id); } }); Here, if a library was downloaded by a debuginfod server bfd->filename it's= the file that is in the debuginfod cache, (for example /home/pablogsal/.cache/debuginfod_client/4a834042b43eec1f2556ef4979828ea3b0= 813adc/executable). Notice that here there are two problems: 1) Libraries that do not have soname will never be registered in the map by set_cbfd_soname_build_id. This is very unfortunate because most shared libraries for dynamic languages such as Python do not have sonames set. 2) The registering into the map from library to buildid in set_cbfd_soname_build_id it's made by SONAME (from the dynamic table). But later, in solib.c in the get_cbfd_soname_build_id() function we can see= the following: soname_build_id_map *mapptr =3D cbfd_soname_build_id_data_key.get (abfd.get ()); if (mapptr =3D=3D nullptr) return {}; auto it =3D mapptr->find (lbasename (soname)); if (it =3D=3D mapptr->end ()) return {}; Here the query is made by the basename of the *soname* argument (lbasename (soname)) but this function is NOT called with the soname but rather the fu= ll path. Indeed, in solib_map_sections() we can observe: gdb::unique_xmalloc_ptr build_id_hexstr =3D get_cbfd_soname_build_id (current_program_space->cbfd, so.so_name.c_str ()); but so.so_name.c_str() is a full path from the linker map. Notice the following: 1) This full path may be different from the one in the previous section bec= ause one comes from the core and the other comes from the linker map. One it's an absolute path and the other can be a symlink. 2) The query is made by full path but the map it's populate from DT_SONAME, which is inconsistent. All of this together means that gdb will never properly load executables th= at are downloaded from the server for shared libraries that do not have sonames set. This is very unfortunate because many extension modules for dynamic languages such as Python don't have sonames and will never work for debugin= fod: $ python Python 3.11.7 (main, Dec 24 2023, 14:12:08) [GCC 13.2.1 20230801] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import _ssl >>> _ssl