When I use the lldb client to connect to the remote gdbserver for debugging, the setting of the exception breakpoint does not take effect

[wangxing-wx]

On Linux when I use lldb client to connect to the remote gdbserver. After the break set -E c++ -h true command is run to set an exception breakpoint, a message is displayed indicating that the exception breakpoint is set successfully. However, the program is not stopped at the catch and throw positions.

[llvmbot]

@llvm/issue-subscribers-lldb

[DavidSpickett]

a message is displayed indicating that the exception breakpoint is set successfully

Can you post the lldb session showing the message?

I tried a simple reproducer with the latest lldb (I didn't use -h true but it seems to not make a difference):

$ cat /tmp/test.cpp
int main() {
  try {
    throw 1;
  }
  catch (int) {
    return 0;
  }
}
$ g++ /tmp/test.cpp -o /tmp/test.o -g
$ gdbserver --version
GNU gdbserver (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
$ gdbserver :12345 /tmp/test.o
$ ./bin/lldb -o "target create /tmp/test.o" -o "log enable gdb-remote packets" -o "gdb-remote 12345" -o "break set -E c++" -o "c"
<...>
intern-state     <  18> send packet: $Z0,100b70003,4#03
intern-state     <   7> read packet: $E01#a6
warning: failed to set breakpoint site at 0x100b70003 for breakpoint -3.1: error: 1 sending the breakpoint request

It appears to be trying to set a software break in unmapped memory (as seen in proc//smaps).
(https://sourceware.org/gdb/onlinedocs/gdb/Packets.html#Packets)

If I do the same with lldb -> lldb-server it works:

intern-state     <  21> send packet: $Z0,fffff7fdae90,4#44
intern-state     <   6> read packet: $OK#9a

(lldb) memory region 0xfffff7fdae90
[0x0000fffff7fcc000-0x0000fffff7fed000) r-x /usr/lib/aarch64-linux-gnu/ld-2.31.so

Are you seeing the same warning in your session?

[wangxing-wx]

I performed the same steps as you did, but the result was different from that of you. The execution ended without any warning, as shown in the following figure:
$ cat test_catch.cpp
int main() {
try {
throw 1;
}
catch (int) {
return 0;
}
}
$ g++ -g -o test_catch.o test_catch.cpp
$ gdbserver --version
GNU gdbserver (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "aarch64-unknown-linux-gnu"
$ gdbserver :1234 test_catch.o
$ ./lldb --version
lldb version 15.0.1
$ ./lldb -o "file /home/wangxing/MPI_Test/test_catch.o" -o "log enable gdb-remote packets" -o "gdb-remote 1234" -o "break set -E c++" -o "c"
<...>
(lldb) break set -E c++
Breakpoint 1: no locations (pending).
(lldb) c
b-remote.async> < 5> send packet: $c#63
b-remote.async> < 72> read packet: $T051d:0*,;1f:c0f3f*"ff0* ;20:900740*';thread:p2d8144.2d8144;core:18;#b5
intern-state < 16> send packet: $qfThreadInfo#bb
intern-state < 19> read packet: $mp2d8144.2d8144#d9
intern-state < 16> send packet: $qsThreadInfo#c8
intern-state < 5> read packet: $l#6c
intern-state < 15> send packet: $m400600,200#55
intern-state < 759> read packet: $0*-800420*'2040*!2021000420'2040*!3021800420'2040*!4022000420'2040*!5022800420'2040*!c023000420'2040*!6023800420'2040*!8024000420'2040*!902fd7bbfa9fd0300913f0 94fd7bc1a8c0035fd60*"00f07bbfa9f0*!f011fe47f910e23f9120021fd61f2003d51f2003d51f2003d510010090110240f91002009120021fd610010090110640f91022009120021fd610010090110a40f91042009120021fd610010090110e40f91062009120021fd610010090111240f91082009120021fd610010090111640f910a2009120021fd610010090111a40f910c2009120021fd610010090111e40f910e2009120021fd610010090112240f91002019120021fd61d0080d21e0080d2e50300aae10340f9e2230091e60300910*"9000201f91030* 9063002491040* 9084002691d8f* 97dbf* 972f0* 14e0*!f000ec47f940*!b4eaf* 17c0035fd60001009000a001910101009021a001913f0* eba0*!54e10* f021e847f9#be
intern-state < 12> send packet: $Hg2d8144#16
intern-state < 6> read packet: $OK#9a
intern-state < 5> send packet: $g#67
intern-state < 402> read packet: $a8e1fbf7f* 0*!10c8f3f*"ff0* d8f3f*"ff0* 1c0*,17fff7f* 0010270)a0*"640*"804dfff7f* 0* 70040*(8e0*;20*+f27083008f6f7f 0* f094b5f7f* 0*!10J900740}0F8412fbf7f 0* c0f3f*"ff0* 900740*-60*+40*-2f77616e6778696e672f4d50495f546573742f746573745f63617463682e6f0*,80*+80*;800100040010*"00100040010*'1082082080020820800208208002082080}0*}0*\1041040010410400104104001041040*+ff0ff0820}0*}0*}0*}0K#a9
intern-state < 15> send packet: $z0,400790,4#6a
intern-state < 6> read packet: $OK#9a
intern-state < 18> send packet: $qShlibInfoAddr#6a
intern-state < 4> read packet: $#00
intern-state < 37> send packet: $qXfer:libraries-svr4:read::0,47fe#95
intern-state < 657> read packet: $l#78
intern-state < 21> send packet: $mfffff7ff1000,200#ed
intern-state < 325> read packet: $c8f3f"ff0*!10*:380240*'4810fff7f* 0*`5909fbf7f* 0110:3a0*}0y23aa010&a840f7f7f* 06f8f 0* 5071fff7f* 0* 7061fff7f* 0D430fd8f3f*"ff0*)20*"010**7011fff7f* 0* c8e5fbf7f* 04fbf7f 0B17fff7f 0* c8fd410*&1017fff7f* 007011fff7f 00e816fff7f 00f8fd410&d8fe410*&c8fe410678fe410&88fe410*'8ff410*&18ff410*&28ff410*&#a5
b-remote.async> < 5> send packet: $c#63
b-remote.async> < 21> read packet: $W0;process:2d8144#62
Process 2982212 resuming
Process 2982212 exited with status = 0 (0x00000000)
(lldb)

This is the full lldb debug log.
lldb_exception.log

[DavidSpickett]

I did some digging into my situation and I think I can explain a bit of what is happening in your log.

First thing to know is that setting an exception breakpoint is going to look for symbols including __cxa_begin_catch, __cxa_throw and __cxa_rethrow (this list comes from the Itanium ABI language runtime plugin). The breakpoint resolver won't find them if we don't know where libstdc++.s0.6 is, as you can see from this working breakpoint:

* thread #1, name = 'test.o', stop reason = breakpoint 1.2
    frame #0: 0x0000fffff7e86510 libstdc++.so.6`__cxa_throw
libstdc++.so.6`__cxa_throw:

If we don't know their locations, we won't find any breakpoint locations (image list will show you if lldb knows about the libraries).

When lldb first connects it will ask gdbserver for locations of libraries:

lldb             <  37> send packet: $qXfer:libraries-svr4:read::0,47fe#95
lldb             <  39> read packet: $l<library-list-svr4 version="1.0"/>#e5
lldb             <   8> send packet: $x0,0#04

See how that's an empty response? Well, I connected gdb to gdbserver and saw the following:

Sending packet: $qXfer:libraries-svr4:read::0,1000#20...Packet received: l<library-list-svr4 version="1.0"/>

Same thing happens, but then there is a fallback:

Sending packet: $vFile:setfs:0#bf...Packet received: F0
Packet vFile:setfs (hostio-setfs) is supported
Sending packet: $vFile:open:2f70726f632f333631323439382f7461736b2f333631323439382f6d617073,0,1c0#87...Packet received: F5
Packet vFile:open (hostio-open) is supported
readahead cache miss 1
Sending packet: $vFile:pread:5,47ff,0#6a...Packet received: F279;aaaaaaaaa000-aaaaaaaab000 r-xp 00000000 fd:00 105119824                  /tmp/test.o\naaaaaaaba000-aaaaaaabc000 rw-p 00000000 fd:00 105119824

What file is that? It's /proc/3612498/task/3612498/maps, so gdbserver is for some reason failing to read the library information via the first packet, then gdb has a fallback which uses the maps file.

lldb doesn't have this fallback which is why lldb -> gdbserver isn't working here. For reasons I don't understand yet, lldb-server does manage to read the library info so lldb -> lldb-server works fine without the need for a fallback.

intern-state     <  39> send packet: $qXfer:libraries-svr4:read::0,131071#8c
intern-state     < 269> read packet: $l<library-list-svr4 version="1.0"><library name="/lib/ld-linux-aarch64.so.1" 
lm="0xfffff7ffea78" l_addr="0xfffff7fcc000" l_ld="0xfffff7ffde18" /><library name="linux-vdso.so.1" lm="0xfffff7fff7e0" 
l_addr="0xfffff7ffc000" l_ld="0xfffff7ffc6c0" /></library-list-svr4>#60

Next questions:

• Why does gdbserver fail the first time and lldb-server does not?
• Even if gdbserver were to be fixed do we want to add the same fallback to lldb-server for compatibility?