public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@arm.com>
To: Andrew Burgess <aburgess@redhat.com>,
	Simon Marchi <simark@simark.ca>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: relax requirement for the map_failed stap probe to be present
Date: Mon, 5 Dec 2022 12:55:35 +0000	[thread overview]
Message-ID: <effda6ff-35fe-677b-e322-268522985ee5@arm.com> (raw)
In-Reply-To: <87k0363vkt.fsf@redhat.com>

On 12/5/22 12:04, Andrew Burgess wrote:
> Luis Machado <luis.machado@arm.com> writes:
> 
>> On 12/5/22 10:09, Andrew Burgess wrote:
>>> Luis Machado <luis.machado@arm.com> writes:
>>>
>>>> On 11/29/22 08:27, Luis Machado wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> This seems to have broken armhf on Ubuntu 22.04.
>>>>>
>>>>> https://builder.sourceware.org/buildbot/#/builders/169/builds/1163
>>>>>
>>>>
>>>> I haven't investigated this. I only spotted it in the sourceware buildbot page. But I'd guess it is something to do
>>>> with thumb mode detection early in the startup.
>>>>
>>>> Ubuntu has moved to not stripping ld.so for armhf because the probe mechanism is not capable of conveying the thumb mode
>>>> information, so gdb has to rely on symbols instead. If the changes have touched this fragile area, it may have broken the
>>>> delicate balance.
>>>
>>> I somehow missed this last week.  I'll take a look today.
>>>
>>> Sorry for the breakage.
>>
>> No problem. For the record, I haven't managed to reproduce this on my Ubuntu 20.04/22.04 setup. I'll have to give it a try on the
>> buildbot machine.
>>
>> Just a heads-up in case this doesn't reproduce for you either.
> 
> I don't have immediate access to a suitable ARM machine.  I'm trying to
> set something up that might work, but given what you report, I'm not too
> hopeful.
> 
> My guess for what is happening though is this:
> 
>    - Previously, when Ubuntu was using glibc 2.35 / 2.36, one of the
>      shared library probes was missing.  As a result GDB would fall back
>      to use the symbol/breakpoint approach.  This worked out just fine
>      for the ARM case as is appears we shouldn't be using the probes
>      anyway.
> 
>    - After my patch GDB no longer cares about the missing probe, and so
>      started trying to use the probes based interface, as this is the
>      preferred strategy.  Unfortunately for ARM this doesn't work :/

It is not exactly that ARM can't use the probe mechanism, but rather that when using the probe mechanism ARM gdb needs to be able to
find some dynamic linker symbols to determine the thumb mode. I'll let you know what I find when trying things on the buildbot
machine.

> 
> I guess the ideal solution would be that glibc didn't include probe
> information if those probes can't then be used for some reason.  I guess
> that will need someone who understands the problem to either raise a
> glibc bug, or propose a glibc fix.
> 
> Until then we probably need to consider GDB based solutions.
> 
> Currently we don't have anyway to avoid particular probes on a
> per-architecture basis, this will probably need a new gdbarch hook
> adding.  I'll see if I can write something like this and test it on the
> buildbot.
> 
> 
> Thanks,
> Andrew
> 


  reply	other threads:[~2022-12-05 12:55 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 [this message]
2022-11-22 15:33 ` Lancelot SIX
2022-11-24 11:39   ` Andrew Burgess

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=effda6ff-35fe-677b-e322-268522985ee5@arm.com \
    --to=luis.machado@arm.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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).