v2.0rc2: SIGLOST when attempting to `run` the target

[pavel-kirienko]

This could be related to #1295.

I am using v2.0rc2 with ATSAMC21 via native probe. The issue did not occur with v1.10. The reproduction is unreliable; it seems like it depends on the level of optimization in the uploaded flash image, meaning that it could be triggered by some obscure dependency somewhere deep.

I can attach and load the image fine without issues nor unusual messages in the console. When I type run, the target is disconnected with the message:

You are now detached from the previous target.
Program terminated with signal SIGLOST, Resource lost.
The program no longer exists.

Full log with set debug remote 1 past the run command (attachment and loading skipped):

(gdb) run
[remote] Sending packet: $vKill;1#6e
[remote] Received Ack
[remote] Packet received: OK
[remote] packet_ok: Packet vKill (kill) is supported
Starting program: /mnt/storage/zubax/software/fluxgrip_software/build/zephyr/zephyr.elf 
[remote] Sending packet: $vRun;#e6
[remote] Received Ack
[remote] Packet received: T05
[remote] packet_ok: Packet vRun (run) is supported
[remote] Sending packet: $qC#b4
[remote] Received Ack
[remote] Packet received: QC1
[remote] Sending packet: $qAttached#8f
[remote] Received Ack
[remote] Packet received: 0
[remote] packet_ok: Packet qAttached (query-attached) is supported
[remote] Sending packet: $qOffsets#4b
[remote] Received Ack
[remote] Packet received: 
[remote] Sending packet: $Hg1#e0
[remote] Received Ack
[remote] Packet received: OK
[remote] Sending packet: $qXfer:features:read:target.xml:0,3fb#46
[remote] Received Ack
[remote] Packet received: m<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target>  <architecture>arm</architecture> <feature name="org.gnu.gdb.arm.m-profile"><reg name="r0" bitsize="32"/><reg name="r1" bitsize="32"/><reg name="r2" bitsize="32"/><reg name="r3" bitsize="32"/><reg name="r4" bitsize="32"/><reg name="r5" bitsize="32"/><reg name="r6" bitsize="32"/><reg name="r7" bitsize="32"/><reg name="r8" bitsize="32"/><reg name="r9" bitsize="32"/><reg name="r10" bitsize="32"/><reg name="r11" bitsize="32"/><reg name="r12 [508 bytes omitted]
[remote] Sending packet: $qXfer:features:read:target.xml:3fb,3fb#11
[remote] Junk: qXfer:features:read:target.xml:3fb,3fb
[remote] Received Ack
[remote] Packet received: m save-restore="no"/><reg name="control" bitsize="8" save-restore="no"/></feature></target>
[remote] Sending packet: $qXfer:features:read:target.xml:455,3fb#b4
[remote] Received Ack
[remote] Packet received: l
[remote] Sending packet: $g#67
[remote] Received Ack
[remote] Packet received: 1800002000000000800000008200000008000020180000201800002014000000000000000800002000000000000000008800004100800020CD040000403200000000004100800020C02A002000000000
[remote] Sending packet: $qXfer:memory-map:read::0,3fb#e5
[remote] Received Ack
[remote] Packet received: m<memory-map><memory type="ram" start="0x20000000" length="0x8000"/><memory type="flash" start="0x00000000" length="0x40000"><property name="blocksize">0x100</property></memory></memory-map>
[remote] Sending packet: $qXfer:memory-map:read::bd,3fb#7b
[remote] Received Ack
[remote] Packet received: l
[remote] Sending packet: $m25440,2#ca
[remote] Received Ack
[remote] Packet received: 024B
[remote] Sending packet: $vCont?#49
[remote] Received Ack
[remote] Packet received: vCont;c;C;s;t
[remote] packet_ok: Packet vCont (verbose-resume) is supported
[remote] Sending packet: $vCont;c#a8
[remote] Received Ack
[remote] wait: enter
[remote] wait: exit
[remote] wait: enter
  [remote]   Notification received: %Stop:W00
[remote] wait: exit
[remote] wait: enter
  [remote] Packet received: O596F7520617265206E6F772064657461636865642066726F6D207468652070726576696F7573207461726765742E0A
You are now detached from the previous target.
[remote] wait: exit
[remote] wait: enter
  [remote] Packet received: X1D
  [remote] select_thread_for_ambiguous_stop_reply: enter
    [remote] select_thread_for_ambiguous_stop_reply: process_wide_stop = 1
    [remote] select_thread_for_ambiguous_stop_reply: first resumed thread is Thread 1
    [remote] select_thread_for_ambiguous_stop_reply: is this guess ambiguous? = 0
  [remote] select_thread_for_ambiguous_stop_reply: exit
[remote] wait: exit

Program terminated with signal SIGLOST, Resource lost.
The program no longer exists.
[remote] Sending packet: $qfThreadInfo#bb
[remote] Received Ack
[remote] Packet received: l
(gdb) 

My .gdbinit also contains:

skip -gfile */arm-*-eabi/*
skip -rfu ^std::.*
set confirm off
set style enabled on
set style sources on
set remote system-call-allowed 1
set mem inaccessible-by-default off

[dragonmux]

This is definitely an interesting mode for it to fail with.. What would be useful to try and help figure out why (as we don't have a ATSAMC21 target and have been unable to observe this behaviour ourself) would be a BMDA log.

Please use BMDA and run blackmagic-bmda -v 5 to get a reasonable set of default diagnostics as that might explain why the X1D packet is being sent back, rather than T02thread:1;.

It would be useful to know too, seeing you mention optimisation levels and such so we guess you're building the firmware yourself, what compiler you're using and what optimisation settings.

[pavel-kirienko]

Yesterday I switched to OpenOCD with ATMEL ICE because this issue was in the way, and v1.10 didn't work for me either because of "Remote failure reply: EFF", which was discussed here some time ago IIRC. Just now I switched my setup back to native BMP with v2.0rc2, and unfortunately I am no longer able to reproduce the problem, neither with BMDA (per your suggestion) nor using the probe directly.

It would be useful to know too, seeing you mention optimisation levels and such so we guess you're building the firmware yourself, what compiler you're using and what optimisation settings.

Apologies for the poor wording on my part. I am using the officially released v2.0rc2 binaries published here on GitHub. The optimization level I was referring to is that of my firmware that I am debugging. It appeared as if the state of the debugged application somehow affected the behavior of the debugger.

Following my inability to reproduce the problem, I tried switching the optimization levels as well as going a few commits back to reproduce the exact state I had yesterday, but I was unable to make it fail again. I am going to continue using BMP now and should it fail again, I will post the logs here.

[dragonmux]

Ah, okie - thank you for the update. We'll leave the issue open in case you're able to reproduce it with the additional logs requested.