Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler
Date: Thu, 20 May 2021 17:29:40 +0200	[thread overview]
Message-ID: <20210520152938.GA31635@delia> (raw)

Hi,

Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
which we can compile into llvm byte code using clang:
...
$ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c
...
and then run using lli, which uses the llvm jit:
...
$ lli test.ll
...

If we run this under gdb, we run into an assert:
...
$ gdb -q -batch -ex run --args /usr/bin/lli test.ll
Dwarf Error: Cannot not find DIE at 0x18a936e7 \
  [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug]

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
src/gdb/jit.c:1178: internal-error: \
  void jit_event_handler(gdbarch*, objfile*): \
  Assertion `jiter->jiter_data != nullptr' failed.
...

This is caused by the following.

When running jit_breakpoint_re_set_internal, we first handle
libLLVM.so.10.debug, and set a jit breakpoint.

Next we handle libLLVM.so.10:
...
(gdb) p the_objfile.original_name
$42 = 0x2494170 "libLLVM.so.10"
...
but the minimal symbols we find are from libLLVM.so.10.debug:
...
(gdb) p reg_symbol.objfile.original_name
$43 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug"
(gdb) p desc_symbol.objfile.original_name
$44 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug"
...
and consequently, the objf_data is the one from libLLVM.so.10.debug:
...
      jiter_objfile_data *objf_data
        = get_jiter_objfile_data (reg_symbol.objfile);
...
and so we hit this:
...
      if (objf_data->cached_code_address == addr)
        continue;
...
and no second jit breakpoint is inserted.

Subsequently, the jit breakpoint is triggered and handled, but when finding
the symbol for the breakpoint address we get:
...
(gdb) p jit_bp_sym.objfile.original_name
$52 = 0x2494170 "libLLVM.so.10"
...

The assert 'jiter->jiter_data != nullptr' triggers because it checks
libLLVM.so.10 while the one with jiter_data setup is libLLVM.so.10.debug.

This fixes the assert:
...
       jiter_objfile_data *objf_data
-        = get_jiter_objfile_data (reg_symbol.objfile);
-        = get_jiter_objfile_data (the_objfile);
...
but consequently we'll have two jit breakpoints, so we also make sure we don't
set a jit breakpoint on separate debug objects like libLLVM.so.10.debug.

Tested on x86_64-linux.

Any comments?

Thanks,
- Tom

[gdb/breakpoint] Fix assert in jit_event_handler

gdb/ChangeLog:

2021-05-20  Tom de Vries  <tdevries@suse.de>

	PR breakpoint/27889
	* jit.c (jit_breakpoint_re_set_internal): Skip separate debug
	objects.  Call get_jiter_objfile_data with the_objfile.

---
 gdb/jit.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gdb/jit.c b/gdb/jit.c
index 296b436c796..be10f197fd6 100644
--- a/gdb/jit.c
+++ b/gdb/jit.c
@@ -807,6 +807,10 @@ jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, program_space *pspace)
 {
   for (objfile *the_objfile : pspace->objfiles ())
     {
+      /* Skip separate debug objects.  */
+      if (the_objfile->separate_debug_objfile_backlink != nullptr)
+	continue;
+
       if (the_objfile->skip_jit_symbol_lookup)
 	continue;
 
@@ -833,7 +837,7 @@ jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, program_space *pspace)
 	}
 
       jiter_objfile_data *objf_data
-	= get_jiter_objfile_data (reg_symbol.objfile);
+	= get_jiter_objfile_data (the_objfile);
       objf_data->register_code = reg_symbol.minsym;
       objf_data->descriptor = desc_symbol.minsym;
 

             reply	other threads:[~2021-05-20 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 15:29 Tom de Vries [this message]
2021-05-20 16:22 ` Simon Marchi via Gdb-patches
2021-05-20 22:04   ` Tom de Vries
2021-05-21 19:12     ` Tom de Vries
2021-05-21 11:27   ` Tom de Vries
2021-05-21 14:07     ` Simon Marchi via Gdb-patches
2021-05-24 15:20     ` Tom Tromey

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=20210520152938.GA31635@delia \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    /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