Server terminates when gdb disconnects

[xhpohanka]

Hello,
I'm not sure if your stlink gdbserver should be persistent, but when I'm using it with stm32vldiscovery kit it terminates allways when gdb disconnects. All other works great.

Here is the log:

st-util -v99
2013-03-06T08:07:12 DEBUG src/stlink-common.c: stlink current mode: mass
2013-03-06T08:07:12 DEBUG src/stlink-common.c: stlink current mode: mass
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_reset ***
2013-03-06T08:07:12 INFO src/stlink-common.c: Loading device parameters....
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_core_id ***
2013-03-06T08:07:12 DEBUG src/stlink-common.c: core_id = 0x1ba01477
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_read_debug32 10016420 is 0xe0042000
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_read_debug32 ffff0080 is 0x1ffff7e0
2013-03-06T08:07:12 INFO src/stlink-common.c: Device connected is: F1 Medium-density Value Line device, id 0x10016420
2013-03-06T08:07:12 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** looking up stlink version
2013-03-06T08:07:12 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2013-03-06T08:07:12 DEBUG src/stlink-common.c: stlink pid     = 0x3744
2013-03-06T08:07:12 DEBUG src/stlink-common.c: stlink version = 0x1
2013-03-06T08:07:12 DEBUG src/stlink-common.c: jtag version   = 0xc
2013-03-06T08:07:12 DEBUG src/stlink-common.c: swim version   = 0x0
2013-03-06T08:07:12 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
Chip ID is 00000420, Core ID is  1ba01477.
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_reset ***
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 3 to 0xe0002000
KARL - should read back as 0x03, not 60 02 00 00
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_read_debug32 261 is 0xe0002000
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002008
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe000200c
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002010
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002014
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002018
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe000201c
init watchpoints
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_read_debug32 1 is 0xe000edfc
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 1000001 to 0xe000edfc
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001028
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001038
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001048
2013-03-06T08:07:12 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001058
Listening at *:4242...
GDB connected.
recv: qSupported:qRelocInsn+
query: Supported;qRelocInsn+
send: PacketSize=3fff;qXfer:memory-map:read+
recv: Hg0
send: 
recv: ?
send: S05
recv: Hc-1
send: 
recv: qC
send: 
recv: qAttached
query: Attached;
send: 
recv: g
2013-03-06T08:07:21 DEBUG src/stlink-common.c: *** stlink_read_all_regs ***
send: 20a107000100000024200000120306009cee2dafffbbdd9bdcbd57b6e01f0020fddf6b6f5bffb198dadd539fe95ff7fa0000000000200020ffffffff60510008
recv: qXfer:memory-map:read::0,fff
query: Xfer;memory-map:read::0,fff
Xfer: type:memory-map;op:read;annex:;addr:0;length:4095
send: m<?xml version="1.0"?><!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN"     "http://sourceware.org/gdb/gdb-memory-map.dtd"><memory-map>  <memory type="rom" start="0x00000000" length="0x20000"/>  <memory type="ram" start="0x20000000" length="0x2000"/>  <memory type="flash" start="0x08000000" length="0x20000">    <property name="blocksize">0x400</property>  </memory>  <memory type="ram" start="0x40000000" length="0x1fffffff"/>  <memory type="ram" start="0xe0000000" length="0x1fffffff"/>  <memory type="rom" start="0x1ffff000" length="0x800"/>  <memory type="rom" start="0x1ffff800" length="0x10"/></memory-map>
recv: qXfer:memory-map:read::27c,d83
query: Xfer;memory-map:read::27c,d83
Xfer: type:memory-map;op:read;annex:;addr:636;length:3459
send: l
recv: m8005160,4
2013-03-06T08:07:21 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
send: 002103e0
recv: qTStatus
query: TStatus;
send: 
recv: qTStatus
query: TStatus;
send: 
recv: k
send: 
cannot send: -2
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_reset ***
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 3 to 0xe0002000
KARL - should read back as 0x03, not 60 02 00 00
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_read_debug32 261 is 0xe0002000
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002008
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe000200c
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002010
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002014
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002018
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe000201c
init watchpoints
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_read_debug32 1 is 0xe000edfc
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 1000001 to 0xe000edfc
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001028
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001038
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001048
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001058
Listening at *:4242...
accept: Bad file descriptor
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_run ***
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_exit_debug_mode ***
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_write_debug32 a05f0000 to 0xe000edf0
2013-03-06T08:07:23 DEBUG src/stlink-common.c: *** stlink_close ***

regards
Jan

[prattmic]

As noted in the GDB documentation (section 20.3.1.2 http://sourceware.org/gdb/onlinedocs/gdb/Server.html), it is expected behavior for a GDB server to terminate after one session. Unfortunately, I don't think that stlink supports extended-remote, which would allow a persistent connection. That would be nice to add...

[prattmic]

Note: extended-remote is officially used to tell GDB to stay connected to the server even when no target is being debugged, however it typically also has the side effect of keeping the server up when GDB disconnects.

[prattmic]

It turns out that I had an old version, and in a more recent commit, someone tried to add support for this, but it does not quite work. Pull request #132 should add working support.

[xhpohanka]

Thank you for fast solution. I was not aware that persistance is not standard behaviour for gdb server. I'm used to use JLink gdb server which has this ability. I will try your patch tomorrow.

[xor-gate]

This should be fixed by @prattmic with PR #132. Feel free to open a new issue when it is not working for v1.2.0 or current master. Thanks all for your contributions.