[PATCH] Fix stop-on-solib event failures

Sergio Durigan Junior sergiodj@sergiodj.net
Fri Aug 16 17:02:00 GMT 2019

On Friday, August 16 2019, Alan Hayward wrote:

>> On 16 Aug 2019, at 13:15, Alan Hayward <Alan.Hayward@arm.com> wrote:
>>> On 15 Aug 2019, at 15:55, Tom Tromey <tom@tromey.com> wrote:
>>>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
>>> Alan> [ This patch replaces "[PATCH] testsuite: disable break-interp.exp for Arm
>>> Alan>   buildbot". Instead of working around the issue, this fixes the issues. ]
>>> Alan> On some Arm targets (namely the buildbot Arm Docker setup) placing breakpoints
>>> Alan> on just the solib dynamic probes will cause the target process to not stop.
>>> Alan> For stop-on-solib to work, a breakpoint also needs placing at the original
>>> Alan> stop address.  This is due to bad placing of the probe addresses in the
>>> Alan> linker.
>>> My understanding is that the probe code is intended to be more efficient
>>> than the old code.  Won't always installing the old-style breakpoint
>>> eliminate the efficiency gain?
>> Right, ok, if that’s the case then yes I agree this patch isn’t right - we shouldn’t
>> be avoiding the optimisation to support broken probes.
>>> If the probes don't work properly on ARM, is there some way to detect that?
>>> Why don't they work?
>> I’ll investigate a little more to see if I can figure out why it’s wrong, and if we
>> can detect it.
>> I could add a UI command to toggle off the optimisation? Not sure I like that.
>> Failing all that I could go back to the previous "disable break-interp.exp for Arm”
>> patch.

[ Adding Gary Benson, who wrote the Probes-based interface.  ]

> Looking into this a little more, if I crtl-c during the timeouts, then continue again
> I get the error "Probes-based dynamic linker interface failed.”
> Doing a quick google I ended up here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1196181

Thanks for investigating this.

Have you double checked to see if the probes have the same problem
describe in this bug?  I.e., the problematic probes contain arguments in
the form of:

  Provider: rtld, Name: init_complete, Args: '-4@.L1212 4@r4'

IOW, the argument contains a label where it should actually contain an

> Looks like this might be the same issue Sergio was looking into - the probes are
> incorrect due to some glibc issue and labels getting removed.
> It sounds to me that the way to stop stop-on-solib hanging is to process the locations
> of the probe (eg - do all the stuff that will later cause the error message) before
> the breakpoints are placed. If it fails, then just insert the old style breakpoint.

I have to take a look at the code, but it may be a good idea to try and
force the evaluation of the arguments before anything else, and to
revert to the old style breakpoints if anything fails.  ISTR that this
was already being done, but I may be wrong.

> Adding Sergio onto the chain.
> Sergio - are you still looking into these issues? Have you specifically seen my issue
> about where break-inter.exp has lots of hangs? And are you still stuck for an Arm
> machine - if you have an AArch64 box I can send you the docker instructions to get
> you up and running with Arm on that.

Well, the bug has apparently been fixed by Florian's commit to glibc,
and since we didn't get any other reports since then, I just assume(d)
it is/was fixed.

I agree it's a good idea to make GDB more resilient against these bugs.
As I said, my initial impression is that GDB can *already* cope with
problems when using the stap probes, but I will have to check more


GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible

More information about the Gdb-patches mailing list