In my personal branch (which hopefully I'll be submitting soon), I
changed hwthread_update_threads() to preserve current_threadid, which fixed
a problem I ran into.

Does this patch also work for you?
--- a/src/rtos/hwthread.c
+++ b/src/rtos/hwthread.c
@@ -87,13 +92,10 @@ static int hwthread_update_threads(struct rtos *rtos)
        enum target_debug_reason current_reason = DBG_REASON_UNDEFINED;

        if (rtos == NULL)
-               return -1;
+               return ERROR_FAIL;

        target = rtos->target;

-       /* wipe out previous thread details if any */
-       rtos_free_threadlist(rtos);
-
        /* determine the number of "threads" */
        if (target->smp) {
                for (head = target->head; head != NULL; head = head->next) {
@@ -107,6 +109,11 @@ static int hwthread_update_threads(struct rtos *rtos)
        } else
                thread_list_size = 1;

+       /* Wipe out previous thread details if any, but preserve threadid.
*/
+       int64_t current_threadid = rtos->current_threadid;
+       rtos_free_threadlist(rtos);
+       rtos->current_threadid = current_threadid;
+
        /* create space for new thread details */
        rtos->thread_details = malloc(sizeof(struct thread_detail) *
thread_list_size);

Tim

On Mon, Apr 8, 2019 at 9:36 AM Daniel Goehring OS via OpenOCD-devel <
openocd-devel@lists.sourceforge.net> wrote:

> Hello,
>
> For the OpenOCD project, I’d like to commit a change to remove the call
> to “rtos_update_threads()” in function gdb_handle_vcont_packet() (file
> gdb_server.c, line 2775), but wanted to get input from the community first.
>
> To provide some environment background, OpenOCD is configured to
> communicate to a GDB client using the GDB remote serial protocol. The
> chip being debugged is an Ampere Computing eMAG 8180 and both
> OpenOCD/GDB are configured SMP multi-core with HW RTOS support enabled.
> The HW RTOS feature allows CPU target selection using the GDB threads
> command.
>
> It’s not clear to me why “rtos_update_threads()” is called here because
> rtos state should already be up-to-date. In addition, this routine calls
> “rtos_free_threadlist()” which wipes out previous thread details such as
> “current_threadid” and “current_thread”. In a GDB multi-cpu (SMP) debug
> environment, resetting current_threadid and current_thread breaks
> functionality on an Ampere Computing eMAG 8180 development platform.
>
> Removing the call fixes the issue I was seeing (current_threadid and
> current_thread values remain intact throughout the call to
> gdb_handle_vcont_packet()).
>
> Specifics below…
>
> File <path>/src/server/gdb_server.c, line 2775
> Lines in question:
> -start-
> /* FIXME: why is this necessary? rtos state should be up-to-date here
> already! */
> rtos_update_threads(target);
> -end-
>
> Thanks,
> Dan Goehring
>
> _______________________________________________
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to