public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: Lancelot SIX <lsix@lancelotsix.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: relax requirement for the map_failed stap probe to be present
Date: Thu, 24 Nov 2022 11:39:40 +0000	[thread overview]
Message-ID: <87v8n437k3.fsf@redhat.com> (raw)
In-Reply-To: <20221122153341.oegu3r7v4nwfukqi@ubuntu.lan>

Lancelot SIX <lsix@lancelotsix.com> writes:

> On Tue, Nov 22, 2022 at 03:09:40PM +0000, Andrew Burgess via Gdb-patches wrote:
>> From glibc 2.35 and later, the "map_failed" stap probe is no longer
>> included in glibc.  The removal of the probe looks like an accident,
>> but it was caused by a glibc commit which meant that the "map_failed"
>> probe could no longer be reached; the compiler than helpfully
>> optimised out the probe.
>> 
>> In GDB, in solib-svr4.c, we have a list of probes that we look for
>> related to the shared library loading detection.  If any of these
>> probes are missing then GDB will fall back to the non-probe based
>> mechanism for detecting shared library loading.  The "map_failed"
>> probe is include in the list of required probes.
>> 
>> This means that on glibc 2.35 (or later) systems, GDB is going to
>> always fall back to the non-probes based mechanism for detecting
>> shared library loading.
>> 
>> I raised a glibc bug to discuss this issue:
>> 
>>   https://sourceware.org/bugzilla/show_bug.cgi?id=29818
>> 
>> But, whatever the ultimate decision from the glibc team, given there
>> are version of glibc in the wild without the "map_failed" probe, we
>> probably should update GDB to handle this situation.
>> 
>> The "map_failed" probe is already a little strange, very early
>> versions of glibc didn't include this probe, so, in some cases, if
>> this probe is missing GDB is happy to ignore it.  In this commit I
>> just expand this logic to make the "map_failed" probe fully optional.
>> 
>> With this commit in place, then, when using a glibc 2.35 or later
>> system, GDB will once again use the stap probes for shared library
>> detection.
>> ---
>>  gdb/solib-svr4.c | 13 +++++++++----
>>  1 file changed, 9 insertions(+), 4 deletions(-)
>> 
>> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
>> index 6acaf87960b..87cd06f251a 100644
>> --- a/gdb/solib-svr4.c
>> +++ b/gdb/solib-svr4.c
>> @@ -2205,10 +2205,15 @@ svr4_find_and_create_probe_breakpoints (svr4_info *info,
>>  
>>        probes[i] = find_probes_in_objfile (os->objfile, "rtld", name);
>>  
>> -      /* The "map_failed" probe did not exist in early
>> -	 versions of the probes code in which the probes'
>> -	 names were prefixed with "rtld_".  */
>> -      if (with_prefix && streq (name, "rtld_map_failed"))
>> +      /* The "map_failed" probe did not exist in early versions of the
>> +	 probes code in which the probes' names were prefixed with
>> +	 "rtld_".
>> +
>> +	 Additionally, the "map_failed" probe was accidentally removed
>> +	 from glibc 2.35 and later, when changes in glibc meant the probe
>> +	 could no longer be reached.  In this case the probe name doesn't
>> +	 have the "rtld_" prefix.  */
>> +      if (streq (probe_info[i].name, "map_failed"))
>>  	continue;
>
> Hi,
>
> Wouldn't this just disable the "map_failed" probe for everyone, even if
> it is available for the current glibc?
>
> Should this become:
>
>   if (streq (probe_info[i].name, "map_failed") && probes[i].empty ())
>     continue
>
> to only ignore this probe if it is missing?

That's a very good point.

In the update below, I've moved the name check inside the immediately
following 'if (probes[i].empty)' block.  I've also added an assert that
the action for the probe is DO_NOTHING - if that action did ever change,
and we then skipped the probe we'd be in trouble.

However, I've also replied to Simon with an alternative approach to this
fix.  I'm not really sure which of the two solutions I prefer, so I'm
posting both to see if there's a preference in the group.

Thanks,
Andrew

---

commit 137177ba43c07aa3e33f5244fcc826e26f2474eb
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Tue Nov 22 12:45:56 2022 +0000

    gdb: relax requirement for the map_failed stap probe to be present
    
    From glibc 2.35 and later, the "map_failed" stap probe is no longer
    included in glibc.  The removal of the probe looks like an accident,
    but it was caused by a glibc commit which meant that the "map_failed"
    probe could no longer be reached; the compiler than helpfully
    optimised out the probe.
    
    In GDB, in solib-svr4.c, we have a list of probes that we look for
    related to the shared library loading detection.  If any of these
    probes are missing then GDB will fall back to the non-probe based
    mechanism for detecting shared library loading.  The "map_failed"
    probe is include in the list of required probes.
    
    This means that on glibc 2.35 (or later) systems, GDB is going to
    always fall back to the non-probes based mechanism for detecting
    shared library loading.
    
    I raised a glibc bug to discuss this issue:
    
      https://sourceware.org/bugzilla/show_bug.cgi?id=29818
    
    But, whatever the ultimate decision from the glibc team, given there
    are version of glibc in the wild without the "map_failed" probe, we
    probably should update GDB to handle this situation.
    
    The "map_failed" probe is already a little strange, very early
    versions of glibc didn't include this probe, so, in some cases, if
    this probe is missing GDB is happy to ignore it.  In this commit I
    just expand this logic to make the "map_failed" probe fully optional.
    
    With this commit in place, then, when using a glibc 2.35 or later
    system, GDB will once again use the stap probes for shared library
    detection.

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 6acaf87960b..c948808f853 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -2205,15 +2205,26 @@ svr4_find_and_create_probe_breakpoints (svr4_info *info,
 
       probes[i] = find_probes_in_objfile (os->objfile, "rtld", name);
 
-      /* The "map_failed" probe did not exist in early
-	 versions of the probes code in which the probes'
-	 names were prefixed with "rtld_".  */
-      if (with_prefix && streq (name, "rtld_map_failed"))
-	continue;
-
       /* Ensure at least one probe for the current name was found.  */
       if (probes[i].empty ())
-	return false;
+	{
+	  /* The "map_failed" probe did not exist in early versions of the
+	     probes code in which the probes' names were prefixed with
+	     "rtld_".
+
+	     Additionally, the "map_failed" probe was accidentally removed
+	     from glibc 2.35 and later, when changes in glibc meant the
+	     probe could no longer be reached, and the compiler optimized
+	     the probe away.  In this case the probe name doesn't have the
+	     "rtld_" prefix.  */
+	  if (streq (probe_info[i].name, "map_failed"))
+	    {
+	      gdb_assert (probe_info[i].action == DO_NOTHING);
+	      continue;
+	    }
+
+	  return false;
+	}
 
       /* Ensure probe arguments can be evaluated.  */
       for (probe *p : probes[i])


      reply	other threads:[~2022-11-24 11:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22 15:09 Andrew Burgess
2022-11-22 15:31 ` Simon Marchi
2022-11-24 10:46   ` Andrew Burgess
2022-11-24 15:10     ` Simon Marchi
2022-11-24 16:13     ` Lancelot SIX
2022-11-28 15:47     ` Pedro Alves
2022-11-28 17:18     ` Andrew Burgess
2022-11-29  8:27       ` Luis Machado
2022-11-29  8:38         ` Luis Machado
2022-12-05 10:09           ` Andrew Burgess
2022-12-05 10:27             ` Luis Machado
2022-12-05 12:04               ` Andrew Burgess
2022-12-05 12:55                 ` Luis Machado
2022-11-22 15:33 ` Lancelot SIX
2022-11-24 11:39   ` Andrew Burgess [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=87v8n437k3.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=lsix@lancelotsix.com \
    /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: link
Be 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).