Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1278959 > unrolled thread

Bug#1125934: gdb: there are 4 unexpected failures on loong64

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1125934: gdb: there are 4 unexpected failures on loong64 zhangdandan <zhangdandan@loongson.cn> - 2026-01-19 09:20 +0100
    Bug#1125934: gdb: there are 4 unexpected failures on loong64 Hector Oron <zumbi@debian.org> - 2026-01-19 09:40 +0100
      Bug#1125934: gdb: there are 4 unexpected failures on loong64 zhangdandan <zhangdandan@loongson.cn> - 2026-01-19 09:50 +0100
    Bug#1125934: gdb: there are 4 unexpected failures on loong64 Tiezhu Yang <yangtiezhu@loongson.cn> - 2026-01-19 10:40 +0100
      Bug#1125934: gdb: there are 4 unexpected failures on loong64 Sergio Durigan Junior <sergiodj@debian.org> - 2026-01-21 04:40 +0100
        Bug#1125934: gdb: there are 4 unexpected failures on loong64 Tiezhu Yang <yangtiezhu@loongson.cn> - 2026-01-21 08:50 +0100
    Bug#1125934: gdb: there are 4 unexpected failures on loong64 Tiezhu Yang <yangtiezhu@loongson.cn> - 2026-01-21 08:20 +0100
      Bug#1125934: gdb: there are 4 unexpected failures on loong64 Sergio Durigan Junior <sergiodj@debian.org> - 2026-01-21 20:50 +0100
    Bug#1125934: gdb: there are 4 unexpected failures on loong64 Miao Wang <shankerwangmiao@gmail.com> - 2026-01-23 15:40 +0100
      Bug#1125934: gdb: there are 4 unexpected failures on loong64 Tiezhu Yang <yangtiezhu@loongson.cn> - 2026-01-24 06:30 +0100
    Bug#1125934: gdb: there are 4 unexpected failures on loong64 Tiezhu Yang <yangtiezhu@loongson.cn> - 2026-01-24 08:00 +0100
      Bug#1125934: gdb: there are 4 unexpected failures on loong64 Tiezhu Yang <yangtiezhu@loongson.cn> - 2026-01-26 19:00 +0100

#1278959 — Bug#1125934: gdb: there are 4 unexpected failures on loong64

Source: gdb
Version: 17.1-1
Severity: normal
Tags: ftbfs, forky, sid
User: debian-loongarch@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the gdb 17.1-1 failed for loong64 in the Debian Package 
Auto-Building environment.
The error log is as follows,
```
         === gdb tests ===

Schedule of variations:
     native-gdbserver

Running target native-gdbserver
Using 
/build/reproducible-path/gdb-17.1/gdb/testsuite/boards/../boards/native-gdbserver.exp 
as board description file for target.
Using 
/build/reproducible-path/gdb-17.1/gdb/testsuite/boards/../boards/gdbserver-base.exp 
as board description file for target.
Using 
/build/reproducible-path/gdb-17.1/gdb/testsuite/boards/../boards/local-board.exp 
as board description file for target.
Using 
/build/reproducible-path/gdb-17.1/gdb/testsuite/config/gdbserver.exp as 
tool-and-target-specific interface file.
Running 
/build/reproducible-path/gdb-17.1/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp 
...
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw 
on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw 
on: thread advanced
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw 
on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw 
on: thread advanced

         === gdb Summary ===

# of expected passes        36
# of unexpected failures    4
......
```
The full build log of gdb can be found at 
https://buildd.debian.org/status/fetch.php?pkg=gdb&arch=loong64&ver=17.1-1&stamp=1768551317&raw=0.

After local analysis and reproduction, there are currently no new findings.
The gdb is blocking the building of over 100 software packages.
Please help analyze and troubleshoot the issue.

Dandan Zhang

[toc] | [next] | [standalone]

#1278963

[Multipart message — attachments visible in raw view] — view raw

Hello,

El lun, 19 ene 2026, 9:17, zhangdandan <zhangdandan@loongson.cn> escribió:

> Source: gdb
> Version: 17.1-1
> Severity: normal
> Tags: ftbfs, forky, sid
> User: debian-loongarch@lists.debian.org
> Usertags: loong64
>
> Dear maintainers,
>
> Compiling the gdb 17.1-1 failed for loong64 in the Debian Package
> Auto-Building environment.
> The error log is as follows,
> ```
>          === gdb tests ===
>
> Schedule of variations:
>      native-gdbserver
>
> Running target native-gdbserver
> Using
> /build/reproducible-path/gdb-17.1/gdb/testsuite/boards/../boards/native-gdbserver.exp
>
> as board description file for target.
> Using
> /build/reproducible-path/gdb-17.1/gdb/testsuite/boards/../boards/gdbserver-base.exp
>
> as board description file for target.
> Using
> /build/reproducible-path/gdb-17.1/gdb/testsuite/boards/../boards/local-board.exp
>
> as board description file for target.
> Using
> /build/reproducible-path/gdb-17.1/gdb/testsuite/config/gdbserver.exp as
> tool-and-target-specific interface file.
> Running
> /build/reproducible-path/gdb-17.1/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp
>
> ...
> FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw
> on: step in ro region
> FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw
> on: thread advanced
> FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw
> on: step in ro region
> FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw
> on: thread advanced
>
>          === gdb Summary ===
>
> # of expected passes        36
> # of unexpected failures    4
> ......
> ```
> The full build log of gdb can be found at
>
> https://buildd.debian.org/status/fetch.php?pkg=gdb&arch=loong64&ver=17.1-1&stamp=1768551317&raw=0
> .
>
> After local analysis and reproduction, there are currently no new findings.
> The gdb is blocking the building of over 100 software packages.
> Please help analyze and troubleshoot the issue.
>

Could you reproduce these issues with upstream GDB 17.1 or latest snapshot?

Regards

>

[toc] | [prev] | [next] | [standalone]

#1278964

[Multipart message — attachments visible in raw view] — view raw

在 2026/1/19 下午4:35, Hector Oron 写道:
> Hello,
>
>
>     After local analysis and reproduction, there are currently no new
>     findings.
>     The gdb is blocking the building of over 100 software packages.
>     Please help analyze and troubleshoot the issue.
>
>
> Could you reproduce these issues with upstream GDB 17.1 or latest 
> snapshot?
>
> Regards
>
These 4 check error is related to testcase 
gdb.base/breakpoint-in-ro-region.exp.

We clone gdb code from debian salsa and test via below method, can not 
reproduce.

```

git clone https://salsa.debian.org/gdb-team/gdb.git
rm -rf build && mkdir -p build && cd build
../gdb/configure
make -j"$(nproc)"
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" 
TESTS="gdb.base/breakpoint-in-ro-region.exp"

```

LoongArch gdb maintainer also helps to analyze, I will ask him to share 
with the details.

Best regards,
Dandan Zhang

Dandan

[toc] | [prev] | [next] | [standalone]

#1278973

On Mon, 19 Jan 2026 16:46:54 +0800 zhangdandan <zhangdandan@loongson.cn> 
wrote:
> 在 2026/1/19 下午4:35, Hector Oron 写道:
> > Hello,
> >
> >
> >     After local analysis and reproduction, there are currently no new
> >     findings.
> >     The gdb is blocking the building of over 100 software packages.
> >     Please help analyze and troubleshoot the issue.
> >
> >
> > Could you reproduce these issues with upstream GDB 17.1 or latest 
> > snapshot?
> >
> > Regards
> >
> These 4 check error is related to testcase 
> gdb.base/breakpoint-in-ro-region.exp.
> 
> We clone gdb code from debian salsa and test via below method, can not 
> reproduce.
> 
> ```
> 
> git clone https://salsa.debian.org/gdb-team/gdb.git
> rm -rf build && mkdir -p build && cd build
> ../gdb/configure
> make -j"$(nproc)"
> make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
> make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" 
> TESTS="gdb.base/breakpoint-in-ro-region.exp"
> 
> ```
> 
> LoongArch gdb maintainer also helps to analyze, I will ask him to share 
> with the details.

I tested on Fedora42, Loongnix25 and Debian for LoongArch64, the test
passed, so I think there may be some differences for the build system
environment, please check or install the latest Debian system if
possible.

Here are the details on Debian:

1. Basic System
https://cdimage.debian.org/cdimage/ports/snapshots/2025-12-06/debian-13.0.0-loong64-NETINST-1.iso

2. APT Source
https://deb.debian.org/debian/

3. Preparation Work
echo "deb https://deb.debian.org/debian unstable main contrib non-free 
non-free-firmware" > /etc/apt/sources.list
apt update
apt upgrade -y
apt install -y sudo vim cmake make git
apt install -y flex bison texinfo arping dejagnu
apt install -y dwarves elfutils binutils
apt install -y gcc g++ llvm clang ssh
apt install -y libgmp-dev libmpfr-dev binutils-dev
apt install -y libcap-dev libncurses-dev libssl-dev
apt install -y firmware-amd-graphics xfce4
apt update
apt upgrade -y
systemctl enable ssh
sudo reboot

4. Test Environment
debian@linux:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux forky/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=forky
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
debian@linux:~$ uname -r
6.18.5+deb14-loong64
debian@linux:~$ uname -m
loongarch64

5. Test Steps
git clone https://salsa.debian.org/gdb-team/gdb.git
rm -rf build && mkdir -p build && cd build
../gdb/configure
make -j"$(nproc)"
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" 
TESTS="gdb.base/breakpoint-in-ro-region.exp"

6. Test Results
(1) Only gdb
debian@linux:~/build$ make check-gdb 
TESTS="gdb.base/breakpoint-in-ro-region.exp"
...
Test run by debian on Mon Jan 19 02:36:21 2026
Native configuration is loongarch64-unknown-linux-gnu

         === gdb tests ===

Schedule of variations:
     unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file 
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for 
target.
Using 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/config/unix.exp 
as tool-and-target-specific interface file.
Running 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp 
...

         === gdb Summary ===

# of expected passes        40
/home/debian/build/gdb/gdb version  17.1 -nw -nx -q -iex "set height 0" 
-iex "set width 0" -data-directory /home/debian/build/gdb/data-directory 
-iex "set interactive-mode on"

         === gdb Summary ===

# of expected passes        40
/home/debian/build/gdb/gdb version  17.1 -nw -nx -q -iex "set height 0" 
-iex "set width 0" -data-directory /home/debian/build/gdb/data-directory 
-iex "set interactive-mode on"

make[3]: Leaving directory '/home/debian/build/gdb/testsuite'
make[2]: Leaving directory '/home/debian/build/gdb/testsuite'
make[1]: Leaving directory '/home/debian/build/gdb'

(2) Using gdbserver
debian@linux:~/build$ make check-gdb 
RUNTESTFLAGS="--target_board=native-gdbserver" 
TESTS="gdb.base/breakpoint-in-ro-region.exp"
...
Test run by debian on Mon Jan 19 02:37:11 2026
Native configuration is loongarch64-unknown-linux-gnu

         === gdb tests ===

Schedule of variations:
     native-gdbserver

Running target native-gdbserver
Using 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/boards/../boards/native-gdbserver.exp 
as board description file for target.
Using 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/boards/../boards/gdbserver-base.exp 
as board description file for target.
Using 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/boards/../boards/local-board.exp 
as board description file for target.
Using 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/config/gdbserver.exp 
as tool-and-target-specific interface file.
Running 
/home/debian/build/gdb/testsuite/../../../gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp 
...

         === gdb Summary ===

# of expected passes        40
/home/debian/build/gdb/gdb version  17.1 -nw -nx -q -iex "set height 0" 
-iex "set width 0" -data-directory /home/debian/build/gdb/data-directory 
-iex "set interactive-mode on"  -iex "set auto-connect-native-target 
off" -iex "set sysroot"

         === gdb Summary ===

# of expected passes        40
/home/debian/build/gdb/gdb version  17.1 -nw -nx -q -iex "set height 0" 
-iex "set width 0" -data-directory /home/debian/build/gdb/data-directory 
-iex "set interactive-mode on"  -iex "set auto-connect-native-target 
off" -iex "set sysroot"

make[3]: Leaving directory '/home/debian/build/gdb/testsuite'
make[2]: Leaving directory '/home/debian/build/gdb/testsuite'
make[1]: Leaving directory '/home/debian/build/gdb'

Thanks,
Tiezhu

[toc] | [prev] | [next] | [standalone]

#1279181

On Monday, 19 January 2026, Tiezhu Yang wrote:

> On Mon, 19 Jan 2026 16:46:54 +0800 zhangdandan
> <zhangdandan@loongson.cn> wrote:
>> 在 2026/1/19 下午4:35, Hector Oron 写道:
>> > Hello,
>> >
>> >
>> >     After local analysis and reproduction, there are currently no new
>> >     findings.
>> >     The gdb is blocking the building of over 100 software packages.
>> >     Please help analyze and troubleshoot the issue.
>> >
>> >
>> > Could you reproduce these issues with upstream GDB 17.1 or latest
>> > snapshot?
>> >
>> > Regards
>> >
>> These 4 check error is related to testcase
>> gdb.base/breakpoint-in-ro-region.exp.
>> We clone gdb code from debian salsa and test via below method, can
>> not reproduce.
>> ```
>> git clone https://salsa.debian.org/gdb-team/gdb.git
>> rm -rf build && mkdir -p build && cd build
>> ../gdb/configure
>> make -j"$(nproc)"
>> make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
>> make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver"
>> TESTS="gdb.base/breakpoint-in-ro-region.exp"
>> ```
>> LoongArch gdb maintainer also helps to analyze, I will ask him to
>> share with the details.
>
> I tested on Fedora42, Loongnix25 and Debian for LoongArch64, the test
> passed, so I think there may be some differences for the build system
> environment, please check or install the latest Debian system if
> possible.

Thanks for testing and providing more details.

Am I correct to assume that the problem is not reproducible with the
latest unstable?

Thanks,

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

[toc] | [prev] | [next] | [standalone]

#1279190

On 2026/1/21 上午11:36, Sergio Durigan Junior wrote:
...

> Thanks for testing and providing more details.
> 
> Am I correct to assume that the problem is not reproducible with the
> latest unstable?

It seems that the previous reply did not sent to you, sorry for that.
Please see the following link for more info:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125934#36

[toc] | [prev] | [next] | [standalone]

#1279187

On Tue, 20 Jan 2026 22:36:47 -0500 Sergio Durigan Junior 
<sergiodj@debian.org> wrote:
> On Monday, 19 January 2026, Tiezhu Yang wrote:

...

> > I tested on Fedora42, Loongnix25 and Debian for LoongArch64, the test
> > passed, so I think there may be some differences for the build system
> > environment, please check or install the latest Debian system if
> > possible.
> 
> Thanks for testing and providing more details.
> 
> Am I correct to assume that the problem is not reproducible with the
> latest unstable?

Yes, I can not reproduce the problem with the upstream mainline [1],
upstream 17.1 [2], debian 17.1-1 [3] and debian 17.1-2 [4] code with
the same test steps [5] on the debian system [6].

(1) upstream mainline
git clone https://sourceware.org/git/binutils-gdb.git gdb
cd gdb
git checkout master
cd ..

(2) upstream 17.1
git clone https://sourceware.org/git/binutils-gdb.git gdb
cd gdb
git checkout gdb-17.1-release
cd ..

(3) debian 17.1-1
git clone https://salsa.debian.org/gdb-team/gdb.git gdb
cd gdb
git checkout debian/17.1-1
cd ..

(4) debian 17.1-2
git clone https://salsa.debian.org/gdb-team/gdb.git gdb
cd gdb
git checkout debian/17.1-2
cd ..

(5) test steps
rm -rf build && mkdir -p build && cd build
../gdb/configure
make -j"$(nproc)"
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" 
TESTS="gdb.base/breakpoint-in-ro-region.exp"

(6) debian system
https://cdimage.debian.org/cdimage/ports/snapshots/2025-12-06/debian-13.0.0-loong64-NETINST-1.iso

Thanks,
Tiezhu

[toc] | [prev] | [next] | [standalone]

#1279260

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, 21 January 2026, Tiezhu Yang wrote:

> On Tue, 20 Jan 2026 22:36:47 -0500 Sergio Durigan Junior
> <sergiodj@debian.org> wrote:
>> On Monday, 19 January 2026, Tiezhu Yang wrote:
>
> ...
>
>> > I tested on Fedora42, Loongnix25 and Debian for LoongArch64, the test
>> > passed, so I think there may be some differences for the build system
>> > environment, please check or install the latest Debian system if
>> > possible.
>> Thanks for testing and providing more details.
>> Am I correct to assume that the problem is not reproducible with the
>> latest unstable?
>
> Yes, I can not reproduce the problem with the upstream mainline [1],
> upstream 17.1 [2], debian 17.1-1 [3] and debian 17.1-2 [4] code with
> the same test steps [5] on the debian system [6].
>
> (1) upstream mainline
> git clone https://sourceware.org/git/binutils-gdb.git gdb
> cd gdb
> git checkout master
> cd ..
>
> (2) upstream 17.1
> git clone https://sourceware.org/git/binutils-gdb.git gdb
> cd gdb
> git checkout gdb-17.1-release
> cd ..
>
> (3) debian 17.1-1
> git clone https://salsa.debian.org/gdb-team/gdb.git gdb
> cd gdb
> git checkout debian/17.1-1
> cd ..
>
> (4) debian 17.1-2
> git clone https://salsa.debian.org/gdb-team/gdb.git gdb
> cd gdb
> git checkout debian/17.1-2
> cd ..
>
> (5) test steps
> rm -rf build && mkdir -p build && cd build
> ../gdb/configure
> make -j"$(nproc)"
> make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"
> make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver"
> TESTS="gdb.base/breakpoint-in-ro-region.exp"
>
> (6) debian system
> https://cdimage.debian.org/cdimage/ports/snapshots/2025-12-06/debian-13.0.0-loong64-NETINST-1.iso

Thanks for the extra info!

OK, then let's wait for the loongarch64 builders to be redeployed and
see if that solves the issue.

Cheers,

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

[toc] | [prev] | [next] | [standalone]

#1279492

[Multipart message — attachments visible in raw view] — view raw

On Wed, 21 Jan 2026 14:47:19 -0500 Sergio Durigan Junior <sergiodj@debian.org> wrote:
> OK, then let's wait for the loongarch64 builders to be redeployed and
> see if that solves the issue.
>

Hi, I managed to reproduce the error in qemu emulated virtual machine, which
lacks the support of hardware watch point.

The failed test case breakpoint-in-ro-region.exp attempts to set the memory
region of the debugged program read-only and force the use of hard breakpoint.
The test bench itself takes the case where breakpoint is not supported into
account, but failed to notice the slight difference of the output when using
gdbserver. That's why the test runs well with normal gdb but fails with
gdb server.

The attached patch can fix the above issue. However, I have no idea why on
the buildd environment, hardware breakpoints cannot be set by gdb.

Cheers,

Miao Wang

[toc] | [prev] | [next] | [standalone]

#1279566

On 2026/1/23 下午10:30, Miao Wang wrote:
> On Wed, 21 Jan 2026 14:47:19 -0500 Sergio Durigan Junior <sergiodj@debian.org> wrote:
>> OK, then let's wait for the loongarch64 builders to be redeployed and
>> see if that solves the issue.
>>
> 
> Hi, I managed to reproduce the error in qemu emulated virtual machine, which
> lacks the support of hardware watch point.

Could you please check whether CONFIG_HAVE_HW_BREAKPOINT is set in your
kernel config? It is usually set by default via the defconfig.

> The failed test case breakpoint-in-ro-region.exp attempts to set the memory
> region of the debugged program read-only and force the use of hard breakpoint.
> The test bench itself takes the case where breakpoint is not supported into
> account, but failed to notice the slight difference of the output when using
> gdbserver. That's why the test runs well with normal gdb but fails with
> gdb server.
> 
> The attached patch can fix the above issue. However, I have no idea why on
> the buildd environment, hardware breakpoints cannot be set by gdb.

If disable CONFIG_PERF_EVENTS, then it will not set
CONFIG_HAVE_HW_BREAKPOINT due to

   select HAVE_HW_BREAKPOINT if PERF_EVENTS

in arch/loongarch/Kconfig of the Linux kernel code, I can reproduce the
following problem:

Running target native-gdbserver
Using 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/boards/../boards/native-gdbserver.exp 
as board description file for target.
Using 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/boards/../boards/gdbserver-base.exp 
as board description file for target.
Using 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/boards/../boards/local-board.exp 
as board description file for target.
Using 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/config/gdbserver.exp 
as tool-and-target-specific interface file.
Running 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp 
...
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw 
on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw 
on: thread advanced
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw 
on: step in ro region
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw 
on: thread advanced

1. Here are the gdb log messages with current code:

(1) Only gdb
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"

```
(gdb) hbreak *0x120000628^M
No hardware breakpoint support in the target.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support 
(no support)

si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: 
auto-hw on: step in ro region (cannot insert hw break)
```

(2) Using gdbserver
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" 
TESTS="gdb.base/breakpoint-in-ro-region.exp"

```
(gdb) hbreak *0x120000628^M
Hardware assisted breakpoint 3 at 0x120000628: file 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c, 
line 22.^M
Warning:^M
Cannot insert hardware breakpoint 3:Remote failure reply: 01.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support 
(support)

si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0:Remote failure reply: 01.^M
^M
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: 
auto-hw on: step in ro region
```

The "hbreak" and "si" test cases are not correct for gdbserver.
It should check "Cannot insert hardware breakpoint" for "hbreak" and "si".
Here are the diff with small change of your patch:

diff --git a/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp 
b/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp
index c29d2f8654e..a077427f31f 100644
--- a/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp
+++ b/gdb/testsuite/gdb.base/breakpoint-in-ro-region.exp
@@ -182,6 +182,9 @@ gdb_test_multiple "hbreak *$main_lo" $test {
      -re "No hardware breakpoint support.*$gdb_prompt $" {
         pass "$test (no support)"
      }
+    -re "Cannot insert hardware breakpoint.*$gdb_prompt $" {
+       pass "$test (no support)"
+    }
      -re "$gdb_prompt $" {
         pass "$test (support)"
         set supports_hbreak 1
@@ -215,7 +218,7 @@ proc test_single_step { always_inserted auto_hw } {

      set test "step in ro region"
      gdb_test_multiple "si" $test {
-       -re "Could not insert hardware breakpoints.*$gdb_prompt $" {
+       -re "Cannot insert hardware breakpoint.*$gdb_prompt $" {
             gdb_assert {!$hw_step && $auto_hw == "on" && 
!$supports_hbreak} \
                 "$test (cannot insert hw break)"
         }

2. Here are the gdb log messages with the above changes:

(1) Only gdb
make check-gdb TESTS="gdb.base/breakpoint-in-ro-region.exp"

```
(gdb) hbreak *0x120000628^M
No hardware breakpoint support in the target.^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support 
(no support)

si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: 
auto-hw on: step in ro region (cannot insert hw break)
```

(2) Using gdbserver
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" 
TESTS="gdb.base/breakpoint-in-ro-region.exp"

```
(gdb) hbreak *0x120000628^M
Hardware assisted breakpoint 3 at 0x120000628: file 
/home/fedora/build/gdb/testsuite/../../../gdb/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c, 
line 22.^M
Warning:^M
Cannot insert hardware breakpoint 3:Remote failure reply: 01.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support 
(no support)

si^M
Note: automatically using hardware breakpoints for read-only addresses.^M
Warning:^M
Cannot insert hardware breakpoint 0:Remote failure reply: 01.^M
^M
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: 
auto-hw on: step in ro region (cannot insert hw break)
```

IMO the problem is related with the Linux kernel config
CONFIG_HAVE_HW_BREAKPOINT which is set by default in the
newer kernel used by Debian official ISO:

https://cdimage.debian.org/cdimage/ports/snapshots/2025-12-06/debian-13.0.0-loong64-NETINST-1.iso

So in order to avoid the problem, one way is to redeploy the above ISO
for the builder, the other way is to modify the GDB test case.

Please send a patch for GDB or let me know that you don't plan to do it
and I'll do it.

Thanks,
Tiezhu

[toc] | [prev] | [next] | [standalone]

#1279574

On 2026/1/24 下午2:11, Miao Wang wrote:
> Control: tags -1 - unreproducible
> 
> Hi,
> 
>> 2026年1月24日 13:23，Tiezhu Yang <yangtiezhu@loongson.cn> 写道：
>>
>> On 2026/1/23 下午10:30, Miao Wang wrote:
>>> On Wed, 21 Jan 2026 14:47:19 -0500 Sergio Durigan Junior <sergiodj@debian.org> wrote:
>>>> OK, then let's wait for the loongarch64 builders to be redeployed and
>>>> see if that solves the issue.
>>>>
>>> Hi, I managed to reproduce the error in qemu emulated virtual machine, which
>>> lacks the support of hardware watch point.
>>
>> Could you please check whether CONFIG_HAVE_HW_BREAKPOINT is set in your
>> kernel config? It is usually set by default via the defconfig.
> 
> Apparently yes. The kernel I have used is from Debian. As I've
> explained in my pervious reply, the reason why hardware watch points is
> not supported in my environment is that qemu does not support this. However,
> I guess that gdb fails to set hardware breakpoints might probably be the
> failure reason for the buildds, but the root cause can't be the same, since
> the kernel used by the buildds is shown in the logs and is also from
> Debian ports, 6.17.12+deb14-loong64.
> 
>> IMO the problem is related with the Linux kernel config
>> CONFIG_HAVE_HW_BREAKPOINT which is set by default in the
>> newer kernel used by Debian official ISO:
>>
>> https://cdimage.debian.org/cdimage/ports/snapshots/2025-12-06/debian-13.0.0-loong64-NETINST-1.iso
>>
>> So in order to avoid the problem, one way is to redeploy the above ISO
>> for the builder, the other way is to modify the GDB test case.
> 
> Apparently this conclusion is not correct since in the kernel used
> by buildds, the above config is enabled, unless the kernel is not
> what was in the ports repo with the same name. If it were the kernel
> problem, there would be no need to reinstall the whole system but
> replacing the kernel would be enough. I suspect that this issue
> might be related to the sbuild unshare environment or related to
> how the buildd are deployed. The root cause for it should be further
> investigated.
> 
>> Please send a patch for GDB or let me know that you don't plan to do it
>> and I'll do it.

I do not know the details of the builder environment.

Anyway, as I described in the previous reply [1], tested with the
official Debian ISO [2] on a physical machine, it should support
the hardware breakpoints, the testcases should pass. If tested on
a virtual machine, it needs to adjust the testcases to make them
happy.

Let us wait for the loongarch64 builders to be redeployed and
see if that solves the issue [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125934#20
[2] 
https://cdimage.debian.org/cdimage/ports/snapshots/2025-12-06/debian-13.0.0-loong64-NETINST-1.iso
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125934#46

Thanks,
Tiezhu

[toc] | [prev] | [next] | [standalone]

#1279842

On 2026/1/24 下午2:57, Tiezhu Yang wrote:
> On 2026/1/24 下午2:11, Miao Wang wrote:
...

> I do not know the details of the builder environment.
> 
> Anyway, as I described in the previous reply [1], tested with the
> official Debian ISO [2] on a physical machine, it should support
> the hardware breakpoints, the testcases should pass. If tested on
> a virtual machine, it needs to adjust the testcases to make them
> happy.
> 
> Let us wait for the loongarch64 builders to be redeployed and
> see if that solves the issue [3].

I discussed offline with Dandan Zhang, she confirmed that the builder
environment is a virtual machine, so the failures is because there is
no support for hardware breakpoints on a virtual machine of LoongArch.

I discussed offline with Miao Wang to reach an agreement, and then I
sent a formal patch [1] to upstream gdb maillist to fix the failures,
it will be merged into upstream master branch and gdb-17-branch ASAP, 
then this patch can be backported to debian gdb.

[1] 
https://inbox.sourceware.org/gdb-patches/20260126100900.23609-1-yangtiezhu@loongson.cn/

Thanks,
Tiezhu

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web