public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "amerey at redhat dot com" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-31635-4717-Jzi77Wj180@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-31635-4717@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=31635 Aaron Merey <amerey at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amerey at redhat dot com --- Comment #2 from Aaron Merey <amerey at redhat dot com> --- (In reply to Pablo Galindo Salgado from comment #0) > 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 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 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 > full path. Indeed, in solib_map_sections() we can observe: > > gdb::unique_xmalloc_ptr<char> build_id_hexstr > = 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 > because 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. 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 gdb would fail to query debuginfod for libraries associated with corefiles much 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 isn't available. -- You are receiving this mail because: You are on the CC list for the bug.
prev parent reply other threads:[~2024-04-19 19:48 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-12 11:48 [Bug corefiles/31635] New: " pablogsal at gmail dot com 2024-04-12 11:49 ` [Bug corefiles/31635] " pablogsal at gmail dot com 2024-04-19 19:48 ` amerey at redhat dot com [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-31635-4717-Jzi77Wj180@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).