[PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Tom de Vries]

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;
 

Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Simon Marchi via Gdb-patches]

On 2021-05-20 11:29 a.m., Tom de Vries wrote:
> 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]

I guess that's unrelated, but do you know if that error is a sign of
something wrong in GDB?

> 
> [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);

It's quite annoying that separate debug info files are represented by
"objfile"s...

> ...
> 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.

Does that fix some test when running the testsuite with the fission
board or something like that?  I think it would be important for this to
be tested.

Otherwise, LGTM.

Simon

Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Tom de Vries]

On 5/20/21 6:22 PM, Simon Marchi wrote:
> On 2021-05-20 11:29 a.m., Tom de Vries wrote:
>> 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]
> 
> I guess that's unrelated, but do you know if that error is a sign of
> something wrong in GDB?
> 

I assumed not (the last binary I checked where that message occurred was
a case of invalid dwarf) but ...

I did a readelf -wi and after 11G I did this grep:
...
$ grep 18a936e7 READELF
 <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram)
    <18aa358f>   DW_AT_specification: <0x18a936e7>
$
...

So this looks like a GDB problem.

I also did:
...
$ gdb -q -readnow
/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug
Reading symbols from
/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug...
Expanding full symbols from
/usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug...
(gdb)
...
so this could be something partial symbols related.

A bit more info:
...
  Compilation Unit @ offset 0x18a23e52:
  ...
 <0><18a23e5d>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <18a23e5e>   DW_AT_producer    : clang version 10.0.1
/home/abuild/rpmbuild/BUILD/llvm-10.0.1.src/stage1/bin/clang-10
--driver-mode=g++ -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D
__STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/ExecutionEngine/Orc
-I ../lib/ExecutionEngine/Orc -I /usr/include/libxml2 -I include -I
../include -fmessage-length=0 -grecord-command-line -O2 -Wall -D
_FORTIFY_SOURCE=0 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -D NDEBUG -fPIC
-fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wimplicit-fallthrough -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -O2
-g -D NDEBUG -fno-exceptions -std=c++14 -MD -MT
lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -MF
lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o.d -o
lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -c
../lib/ExecutionEngine/Orc/LLJIT.cpp
    <18a23e62>   DW_AT_language    : 33 (C++14)
    <18a23e64>   DW_AT_name        : ../lib/ExecutionEngine/Orc/LLJIT.cpp
 ...
 <1><18a936d4>: Abbrev Number: 71 (DW_TAG_subprogram)
 <2><18a936d5>: Abbrev Number: 174 (DW_TAG_class_type)
    <18a936d7>   DW_AT_calling_convention: 5    (pass by value)
    <18a936d8>   DW_AT_byte_size   : 8
    <18a936d9>   DW_AT_decl_file   : 185
    <18a936da>   DW_AT_decl_line   : 78
 <3><18a936db>: Abbrev Number: 9 (DW_TAG_member)
    <18a936dc>   DW_AT_name        : this
    <18a936e0>   DW_AT_type        : <0x18a8bb20>
    <18a936e4>   DW_AT_decl_file   : 185
    <18a936e5>   DW_AT_decl_line   : 78
    <18a936e6>   DW_AT_data_member_location: 0
 <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram)
    <18a936e9>   DW_AT_name        : operator()
    <18a936ed>   DW_AT_decl_file   : 185
    <18a936ee>   DW_AT_decl_line   : 78
    <18a936ef>   DW_AT_type        : <0x18a557ad>
    <18a936f3>   DW_AT_declaration : 1
    <18a936f3>   DW_AT_external    : 1
    <18a936f3>   DW_AT_accessibility: 1 (public)

  ...

 <1><18aa3589>: Abbrev Number: 251 (DW_TAG_subprogram)
    <18aa358b>   DW_AT_linkage_name: _ZZN4llvm10ThreadPool4waitEvENK3$_1clEv
    <18aa358f>   DW_AT_specification: <0x18a936e7>
    <18aa3593>   DW_AT_inline      : 1  (inlined)
    <18aa3594>   DW_AT_object_pointer: <0x18aa3598>
  ...
  Compilation Unit @ offset 0x18aa33d6:
...

Thanks,
- Tom

Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On 5/20/21 6:22 PM, Simon Marchi wrote:
> It's quite annoying that separate debug info files are represented by
> "objfile"s...
> 

Yeah, indeed.

And you could even say that that's fine, but question whether they
should be in the objfiles list, that is, have the default behaviour of:
...
   for (objfile *the_objfile : pspace->objfiles ())
     {
+      /* Skip separate debug objects.  */
+      if (the_objfile->separate_debug_objfile_backlink != nullptr)
+       continue;
...
without having to specify this, and if you need to access the separate
debuginfo files, use the specific iterator for this.

>> ...
>> 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.
> 
> Does that fix some test when running the testsuite with the fission
> board or something like that?

No, though I ran into another problem :) while playing around with the
jit test-cases and target boards  (
https://sourceware.org/bugzilla/show_bug.cgi?id=27893 ).  [ And yet
another problem while looking into the missing DIE problem (
https://sourceware.org/bugzilla/show_bug.cgi?id=27894 ).

>  I think it would be important for this to
> be tested.
> 

I wrote this target board file, which does trigger this assert in the
jit test-cases, and verified that the patch fixes all of them.

During testing of the target board, I ran into another assert in
gdb.python/py-objfile.exp, will file that as well.  WDYT?

Thanks,
- Tom

[-- Attachment #2: 0002-gdb-testsuite-Add-target-board-cc-with-gnu-debuglink.exp.patch --]
[-- Type: text/x-patch, Size: 4289 bytes --]

[gdb/testsuite] Add target board cc-with-gnu-debuglink.exp

Add target board cc-with-gnu-debuglink.exp that splits off debuginfo into 
a
seperate .debug file and links to it using .gnu_debuglink.

Tested on x86_64-linux.

gdb/ChangeLog:

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

	* contrib/cc-with-tweaks.sh: Handle -l.

gdb/testsuite/ChangeLog:

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

	* boards/cc-with-gnu-debuglink.exp: New file.

---
 gdb/contrib/cc-with-tweaks.sh                  | 46 +++++++++++++++++++++++++-
 gdb/testsuite/boards/cc-with-gnu-debuglink.exp | 26 +++++++++++++++
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/gdb/contrib/cc-with-tweaks.sh b/gdb/contrib/cc-with-tweaks.sh
index 2eda76a89c2..8653dfb260e 100755
--- a/gdb/contrib/cc-with-tweaks.sh
+++ b/gdb/contrib/cc-with-tweaks.sh
@@ -45,6 +45,7 @@
 # -i make an index (.gdb_index)
 # -n make a dwarf5 index (.debug_names)
 # -p create .dwp files (Fission), you need to also use gcc option -gsplit-dwarf
+# -l creates separate debuginfo files linked to using .gnu_debuglink
 # If nothing is given, no changes are made
 
 myname=cc-with-tweaks.sh
@@ -83,6 +84,7 @@ want_dwz=false
 want_multi=false
 want_dwp=false
 want_objcopy_compress=false
+want_gnu_debuglink=false
 
 while [ $# -gt 0 ]; do
     case "$1" in
@@ -92,6 +94,7 @@ while [ $# -gt 0 ]; do
 	-n) want_index=true; index_options=-dwarf-5;;
 	-m) want_multi=true ;;
 	-p) want_dwp=true ;;
+	-l) want_gnu_debuglink=true ;;
 	*) break ;;
     esac
     shift
@@ -158,7 +161,12 @@ fi
 
 get_tmpdir ()
 {
-    tmpdir=$(dirname "$output_file")/.tmp
+    subdir="$1"
+    if [ "$subdir" = "" ]; then
+	subdir=.tmp
+    fi
+
+    tmpdir=$(dirname "$output_file")/"$subdir"
     mkdir -p "$tmpdir"
 }
 
@@ -234,4 +242,40 @@ if [ "$want_dwp" = true ]; then
     fi
 fi
 
+if [ "$want_gnu_debuglink" = true ]; then
+    # Based on gdb_gnu_strip_debug.
+
+    # Gdb looks for the .gnu_debuglink file in the .debug subdirectory
+    # of the directory of the executable.
+    get_tmpdir .debug
+
+    stripped_file="$tmpdir"/$(basename "$output_file").stripped
+    debug_file="$tmpdir"/$(basename "$output_file").debug
+
+    # Create stripped and debug versions of output_file.
+    strip --strip-debug "${output_file}" \
+	  -o "${stripped_file}"
+    rc=$?
+    [ $rc != 0 ] && exit $rc
+    strip --only-keep-debug "${output_file}" \
+	  -o "${debug_file}"
+    rc=$?
+    [ $rc != 0 ] && exit $rc
+
+    # The .gnu_debuglink is supposed to contain no leading directories.
+    link=$(basename "${debug_file}")
+
+    (
+	# Temporarily cd to tmpdir to allow objcopy to find $link
+	cd "$tmpdir" || exit 1
+
+	# Overwrite output_file with stripped version containing
+	# .gnu_debuglink to debug_file.
+	objcopy --add-gnu-debuglink="$link" "${stripped_file}" \
+		"${output_file}"
+	rc=$?
+	[ $rc != 0 ] && exit $rc
+    )
+fi
+
 exit $rc
diff --git a/gdb/testsuite/boards/cc-with-gnu-debuglink.exp b/gdb/testsuite/boards/cc-with-gnu-debuglink.exp
new file mode 100644
index 00000000000..ca977d9f165
--- /dev/null
+++ b/gdb/testsuite/boards/cc-with-gnu-debuglink.exp
@@ -0,0 +1,26 @@
+# Copyright 2021 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This file is a dejagnu "board file" and is used to run the testsuite
+# with contrib/cc-with-tweaks.sh -l.
+#
+# Example usage:
+# bash$ cd $objdir
+# bash$ make check-gdb \
+#   RUNTESTFLAGS='--target_board=cc-with-gnu-debuglink'
+#
+
+set CC_WITH_TWEAKS_FLAGS "-l"
+load_board_description "cc-with-tweaks"

Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Simon Marchi via Gdb-patches]

On 2021-05-21 7:27 a.m., Tom de Vries wrote:
> On 5/20/21 6:22 PM, Simon Marchi wrote:
>> It's quite annoying that separate debug info files are represented by
>> "objfile"s...
>>
> 
> Yeah, indeed.
> 
> And you could even say that that's fine, but question whether they
> should be in the objfiles list, that is, have the default behaviour of:
> ...
>    for (objfile *the_objfile : pspace->objfiles ())
>      {
> +      /* Skip separate debug objects.  */
> +      if (the_objfile->separate_debug_objfile_backlink != nullptr)
> +       continue;
> ...
> without having to specify this, and if you need to access the separate
> debuginfo files, use the specific iterator for this.

I think that would be a good idea to explore.

In my opinion, the fact that an objfile has separate debug info should
be pretty much transparent to the rest of GDB.  So I think it would make
sense for these special objfiles to be hidden, unless you explicitly ask
for them.

>>> ...
>>> 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.
>>
>> Does that fix some test when running the testsuite with the fission
>> board or something like that?
> 
> No, though I ran into another problem :) while playing around with the
> jit test-cases and target boards  (
> https://sourceware.org/bugzilla/show_bug.cgi?id=27893 ).

Well, good news that you caught it!

> [ And yet
> another problem while looking into the missing DIE problem (
> https://sourceware.org/bugzilla/show_bug.cgi?id=27894 ).

I do stumble on that sometimes.

> 
>>  I think it would be important for this to
>> be tested.
>>
> 
> I wrote this target board file, which does trigger this assert in the
> jit test-cases, and verified that the patch fixes all of them.

I thought that fission meant "separate debug info", but I think I was
wrong... I always confuse fission and separate debug info.

We don't already have a board file that generates separate debug info,
in that sense:

  https://sourceware.org/gdb/current/onlinedocs/gdb/Separate-Debug-Files.html

?  Looks like we don't, so it would be useful to add one.  Since there
are two ways of specifying separate debug info (by debuglink and by
build-id, I think it would be nice to have a board for each.  But just
adding the debuglink one would already be an improvement.  And once the
separate debug info file is found, I guess the code paths don't differ
much based on through which method the file was found.

> During testing of the target board, I ran into another assert in
> gdb.python/py-objfile.exp, will file that as well.  WDYT?

I think that board file should be added.

Simon

Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Tom de Vries]

On 5/21/21 12:04 AM, Tom de Vries wrote:
> On 5/20/21 6:22 PM, Simon Marchi wrote:
>> On 2021-05-20 11:29 a.m., Tom de Vries wrote:
>>> 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]
>>
>> I guess that's unrelated, but do you know if that error is a sign of
>> something wrong in GDB?
>>
> 
> I assumed not (the last binary I checked where that message occurred was
> a case of invalid dwarf) but ...
> 
> I did a readelf -wi and after 11G I did this grep:
> ...
> $ grep 18a936e7 READELF
>  <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram)
>     <18aa358f>   DW_AT_specification: <0x18a936e7>
> $
> ...
> 
> So this looks like a GDB problem.
> 
> I also did:
> ...
> $ gdb -q -readnow
> /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug
> Reading symbols from
> /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug...
> Expanding full symbols from
> /usr/lib/debug/usr/lib64/libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug...
> (gdb)
> ...
> so this could be something partial symbols related.
> 
> A bit more info:
> ...
>   Compilation Unit @ offset 0x18a23e52:
>   ...
>  <0><18a23e5d>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     <18a23e5e>   DW_AT_producer    : clang version 10.0.1
> /home/abuild/rpmbuild/BUILD/llvm-10.0.1.src/stage1/bin/clang-10
> --driver-mode=g++ -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D
> __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/ExecutionEngine/Orc
> -I ../lib/ExecutionEngine/Orc -I /usr/include/libxml2 -I include -I
> ../include -fmessage-length=0 -grecord-command-line -O2 -Wall -D
> _FORTIFY_SOURCE=0 -fstack-protector-strong -funwind-tables
> -fasynchronous-unwind-tables -fstack-clash-protection -D NDEBUG -fPIC
> -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wimplicit-fallthrough -Wno-noexcept-type
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
> -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -O2
> -g -D NDEBUG -fno-exceptions -std=c++14 -MD -MT
> lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -MF
> lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o.d -o
> lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/LLJIT.cpp.o -c
> ../lib/ExecutionEngine/Orc/LLJIT.cpp
>     <18a23e62>   DW_AT_language    : 33 (C++14)
>     <18a23e64>   DW_AT_name        : ../lib/ExecutionEngine/Orc/LLJIT.cpp
>  ...
>  <1><18a936d4>: Abbrev Number: 71 (DW_TAG_subprogram)
>  <2><18a936d5>: Abbrev Number: 174 (DW_TAG_class_type)
>     <18a936d7>   DW_AT_calling_convention: 5    (pass by value)
>     <18a936d8>   DW_AT_byte_size   : 8
>     <18a936d9>   DW_AT_decl_file   : 185
>     <18a936da>   DW_AT_decl_line   : 78
>  <3><18a936db>: Abbrev Number: 9 (DW_TAG_member)
>     <18a936dc>   DW_AT_name        : this
>     <18a936e0>   DW_AT_type        : <0x18a8bb20>
>     <18a936e4>   DW_AT_decl_file   : 185
>     <18a936e5>   DW_AT_decl_line   : 78
>     <18a936e6>   DW_AT_data_member_location: 0
>  <3><18a936e7>: Abbrev Number: 175 (DW_TAG_subprogram)
>     <18a936e9>   DW_AT_name        : operator()
>     <18a936ed>   DW_AT_decl_file   : 185
>     <18a936ee>   DW_AT_decl_line   : 78
>     <18a936ef>   DW_AT_type        : <0x18a557ad>
>     <18a936f3>   DW_AT_declaration : 1
>     <18a936f3>   DW_AT_external    : 1
>     <18a936f3>   DW_AT_accessibility: 1 (public)
> 
>   ...
> 
>  <1><18aa3589>: Abbrev Number: 251 (DW_TAG_subprogram)
>     <18aa358b>   DW_AT_linkage_name: _ZZN4llvm10ThreadPool4waitEvENK3$_1clEv
>     <18aa358f>   DW_AT_specification: <0x18a936e7>
>     <18aa3593>   DW_AT_inline      : 1  (inlined)
>     <18aa3594>   DW_AT_object_pointer: <0x18aa3598>
>   ...
>   Compilation Unit @ offset 0x18aa33d6:
> ...

Filed here ( https://sourceware.org/bugzilla/show_bug.cgi?id=27898 ).

Thanks,
- Tom

Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler

[Tom Tromey]

>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

Simon> It's quite annoying that separate debug info files are represented by
Simon> "objfile"s...

Tom> Yeah, indeed.

Tom> And you could even say that that's fine, but question whether they
Tom> should be in the objfiles list, that is, have the default behaviour of:

I've long thought this was a design error, and that having the separate
debug objfile be replaced with supplementary BFDs attached to the main
objfile would be a better design.

If someone wants to implement this, I'm all for it.

Tom