From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 59DBF39960C6; Tue, 30 Aug 2022 08:06:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 59DBF39960C6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1661846800; bh=gbE+po/RvBanjd2HtlfDpdgBEJrUqAhygRYKSpAZf08=; h=From:To:Subject:Date:From; b=ya1KuTyEosOcZqPT/w3ArM3aiwJ6V1UPPQNKKv9fQDmdPA9d2R29j2GXorvZhCEIZ qTqxhnP8aEszgeJnFo+JKOZUnZK3oSWqOg+EOfcS2axTxYboHFbr2+EoY8rYeeeL4Y Z2P66fOG5bv2D4OTm7ymwVzoVuDDgb0dQ+oVQDFI= From: "torbjorn.svensson at st dot com" To: gdb-prs@sourceware.org Subject: [Bug remote/29538] New: Running "info threads" multiple times produce different output when target has been halted the entire time Date: Tue, 30 Aug 2022 08:06:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: remote X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: torbjorn.svensson at st dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29538 Bug ID: 29538 Summary: Running "info threads" multiple times produce different output when target has been halted the entire time Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: remote Assignee: unassigned at sourceware dot org Reporter: torbjorn.svensson at st dot com Target Milestone: --- Created attachment 14303 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D14303&action=3Ded= it GDB output with "set debug remote 1" When using 27d582267a1d06e94661979f8893799ac235a768 (master as of this writ= ing) with SEGGER J-Link GDB server (with FreeRTOS support enabled) causes GDB to believe that there are 2 threads when there in fact is only one, but the th= read changed id. The board used is a STM3240G-EVAL board, but I'm sure the same thing can be reproduced on a native GDB server with some tweaking of the RSP replies. The SEGGER J-Link GDB server (version 7.70c) is launched using this command: ./JLinkGDBServerCLExe -port 2331 -s -device STM32F407IG -endian little -spe= ed 4000 -if swd -vd -rtos GDBServer/RTOSPlugin_FreeRTOS.so The GDB client is launched using this command: arm-none-eabi-gdb -x /tmp/segger/commands The content of /tmp/segger/commands is: set debug threads 1 set target-async on file /tmp/segger/40g-eval.elf target remote :2331 p "info1" info threads p "thread1" thread p "info2" info threads p "thread2" thread monitor reset break main continue quit The output from GDB is: GNU gdb (GDB) 13.0.50.20220829-git Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=3Dx86_64-linux-gnu --target=3Darm-none-e= abi". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". Warning: 'set target-async', an alias for the command 'set mi-async', is deprecated. Use 'set mi-async'. [threads] add_thread_silent: add thread to inferior 1, ptid 42000.57005.0, target remote [threads] new_thread: creating a new thread object, inferior 1, ptid 42000.57005.0 Reset_Handler () at ../Core/Startup/startup_stm32f407ighx.s:63 63 ../Core/Startup/startup_stm32f407ighx.s: No such file or directory. $1 =3D "info1" [threads] add_thread_silent: add thread to inferior 1, ptid 42000.0.0, targ= et remote [threads] new_thread: creating a new thread object, inferior 1, ptid 42000.= 0.0 [New Remote target] Id Target Id Frame * 1 Thread 57005 Reset_Handler () at ../Core/Startup/startup_stm32f407ighx.s:63 2 Remote target Reset_Handler () at ../Core/Startup/startup_stm32f407ighx.s:63 $2 =3D "thread1" [Current thread is 1 (Thread 57005)] $3 =3D "info2" [threads] delete_thread_1: deleting thread 42000.57005.0, silent =3D 0 Id Target Id Frame 2 Remote target Reset_Handler () at ../Core/Startup/startup_stm32f407ighx.s:63 The current thread has terminated. See `help thread'. $4 =3D "thread2" [Current thread is 1 (Thread 57005) (exited)] Resetting target Breakpoint 1 at 0x80004d8: file ../Core/Src/main.c, line 118. /tmp/segger/commands:22: Error in sourced command file: Cannot execute this command without a live selected thread. On line 22 in /tmp/segger/commands, the command is "continue". As can be seen, the "continue" command fails due to that GDB gets confused = by the number of threads. Looking at the RSP log(attached due to that bugzilla thought it was spam), I can see a few things that might be the root cause of the problem. 1. Why is the thread list requested prior to running the qSymbols dance? If it's delayed until after the qSymbols, then the "0000dead" would likely nev= er be received by the GDB client. 2. It looks like a new thread is detected on the 1st "info threads", but the old thread is removed on the 2nd "info threads". I suppose both the removal= and the creation should be done in the 1st "info threads", or even better, just update the id of the remote thread. Is there any reason to remove thread 1 and create thread 2 when GDB thought there was one thread and after the qfThreadInfo RSP-command, there is still only one thread, but with different id? 3. The thread id "00000000" is a bad id, but overriding the RSP response wi= th another id, like "42", does not help either. The bad usage of thread id "0"= has been reported to SEGGER and hopefully, they will change this in a future version of their software. The problems above has been seen with various released versions of GDB too,= so it's not a regression. It's also present in all-stop mode. I've not checked= if the same problem is visible in non-stop mode and SEGGER J-Link GDB server d= oes not support non-stop mode. --=20 You are receiving this mail because: You are on the CC list for the bug.=