[PATCH 2/2] jit: remove bp locations when unregistering jit code

Strasuns, Mihails mihails.strasuns@intel.com
Mon May 25 10:07:09 GMT 2020


Hello,

I will focus on the design related question for now:

> -----Original Message-----
> From: Simon Marchi <simark@simark.ca>
> Sent: Sunday, May 24, 2020 5:02 PM
> To: Strasuns, Mihails <mihails.strasuns@intel.com>; gdb-
> patches@sourceware.org
> Subject: Re: [PATCH 2/2] jit: remove bp locations when unregistering jit code
> 
> I'm not very familiar with how breakpoint locations are computed and
> updated (I just know it's complicated). But I confirm that the test shows the
> problem without the fix applied and passes with the fix applied.  I'd like if
> some other maintainer more familiar with this area could review this part.
> 
> I'd be really curious to understand how GDB handles this when it comes to
> shared libraries.  Let's imagine the same case, but using shared libraries.
> When a shared library is unloaded, the breakpoint locations that were in that
> library must be forgotten somehow?  If so through which hook / mechanism?

This is something I have initially looked into myself didn't find a clear answer in GDB sources :-)

bp_location defines this field:

---
  /* This location's address is in an unloaded solib, and so this
     location should not be inserted.  It will be automatically
     enabled when that solib is loaded.  */
  bool shlib_disabled = false;
---

What I don't understand though is that once set to true/1, this field is never reset back to 0. My guess is that this is intended to work in a similar way to my fix, i.e. that a new breakpoint location gets created for the new load rather than the old one being recreated. However I am not entirely sure.

There is a fair amount of differences between semantics of jit and shared libraries, so I decided to start with an independent fix and ask in this mail list for someone who knows better.

Two important notes:

- there is a `disable_breakpoints_in_freed_objfile` hook in breakpoint.c which looks like it should have covered this case but somehow it is not enough.
- the issue in the test case only manifests if reloaded object file uses exactly the same base address and thus breakpoint location looks the same to GDB

BR,
Mihails

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


More information about the Gdb-patches mailing list