From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2C18F3849AF7; Fri, 19 Apr 2024 19:48:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C18F3849AF7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1713556097; bh=1GXa5uKAAKmLFFkGZcHEnb/9gX74ggq1PMaQkEFf4vU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k8GLu8QEYem6stuK9B2HHhPTcK2EsLGErEIdyoAAQMh0dxx0r51yzci8pdTCdLv9n RDq6LI60Dlt5XoGv8cxacU5xBRo4RD5+NBDQmkQ/DCqSJQs6Qwbl0JehzYtbbpTvff JQrSB6SakgT+QywzP8X3I+1KUJfJcOalBRpXfen4= From: "amerey at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug corefiles/31635] debuginfod cannot correctly fetch shared libraries without soname from server due to inconsistency Date: Fri, 19 Apr 2024 19:48:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed 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: amerey at redhat 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: cc Message-ID: In-Reply-To: References: 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 Aaron Merey changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amerey at redhat dot com --- Comment #2 from Aaron Merey --- (In reply to Pablo Galindo Salgado from comment #0)=20 > 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). One challenge for getting debuginfod to work with corefiles is figuring out= =20 which library buildid in the corefile corresponds to a particular library that gdb is unable to open in solib_map_sections. Sonames are used because we can create a soname to buildid mapping from the corefile and then use=20 this mapping to get the right buildid for the debuginfod query when a shared library can't otherwise be found by gdb in solib_map_sections. > [...] > 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= =20 > full path. Indeed, in solib_map_sections() we can observe: >=20 > gdb::unique_xmalloc_ptr build_id_hexstr > =3D get_cbfd_soname_build_id (current_program_space->cbfd, > so.so_name.c_str ()); >=20 > but so.so_name.c_str() is a full path from the linker map. Notice the=20 > following: >=20 > 1) This full path may be different from the one in the previous section > because one comes from the core and the other comes from the linker map. = One=20 > 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_SONAM= E, > which is inconsistent. AFAIK when the library has a soname, the basename in get_cbfd_soname_build_= id should generally match a soname in the map. If this wasn't the case then g= db=20 would fail to query debuginfod for libraries associated with corefiles much= =20 more often. I'll look into what paths gdb uses in solib_map_sections for libraries with no soname. Maybe it's possible to create a path-to-buildid map from the corefile that we could use instead of the the soname-to-buildid map when a soname is= n't available. --=20 You are receiving this mail because: You are on the CC list for the bug.=