public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug dynamic-link/29818] New: STAP probe map_failed is no longer generated.
@ 2022-11-22 12:29 aburgess at redhat dot com
  2022-11-22 12:30 ` [Bug dynamic-link/29818] " aburgess at redhat dot com
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: aburgess at redhat dot com @ 2022-11-22 12:29 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=29818

            Bug ID: 29818
           Summary: STAP probe map_failed is no longer generated.
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: aburgess at redhat dot com
  Target Milestone: ---

Created attachment 14472
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14472&action=edit
Remove the map_failed probe.

While working on GDB, I noticed that in recent glibc, the map_failed probe was
no longer being generated within the dynamic linker.

The reason is that the 'map_failed' probe is being optimised out by the
compiler after this commit:

  commit ed3ce71f5c64c5f07cbde0ef03554ea8950d8f2c
  Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
  Date:   Thu Nov 11 09:28:21 2021 -0300

      elf: Move la_activity (LA_ACT_ADD) after _dl_add_to_namespace_list() (BZ
#28062)

The problem is that the map_failed probe is guarded like this:

          if (make_consistent && r != NULL)
            {
              r->r_state = RT_CONSISTENT;
              _dl_debug_state ();
              LIBC_PROBE (map_failed, 2, nsid, r);
            }

After the above commit the make_consistent variable can never be true when this
block of code is reached, as such, the compiler has optimised away this block,
including the map_failed probe within it.

Both the map_start and map_failed probes are in the function
_dl_map_object_from_fd.  Before the above commit it is was possible to reach
the map_start probe, and then later in the function, decide that actually, we
couldn't map the requested file for some reason.

We would then exit _dl_map_object_from_fd, but first we would pass through the
map_failed probe, this would allow observers to know that the mapping,
identified by the previous map_start probe, had failed.

After the above commit, the map_start probe is now only reached at the very end
of the function _dl_map_object_from_fd, when all other error checks have
already been completed.  As such, there is no longer a need for a map_failed
probe.  If an observer sees map_start, then they can know that the mapping will
proceed.

This bug is really just me asking for confirmation of the above understanding. 
From the GDB side, we were never actually using map_start / map_failed, but we
did check for both probes, so the absence of map_failed was causing GDB to not
make use of the probes.  I already plan to remove the map_failed check from GDB
given there are glibc in the wild without that probe.  But it would be nice to
confirm that the probe is now deprecated.

I've attached a patch that removes the map_failed probe, but this is completely
untested.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-11-30 12:02 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-22 12:29 [Bug dynamic-link/29818] New: STAP probe map_failed is no longer generated aburgess at redhat dot com
2022-11-22 12:30 ` [Bug dynamic-link/29818] " aburgess at redhat dot com
2022-11-22 15:11 ` simon.marchi at polymtl dot ca
2022-11-22 15:12 ` lsix at lancelotsix dot com
2022-11-23 14:06 ` adhemerval.zanella at linaro dot org
2022-11-28 15:35 ` pedro at palves dot net
2022-11-28 17:56 ` fche at redhat dot com
2022-11-30 12:02 ` adhemerval.zanella at linaro dot org

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).