Tim and Matthias,
I'd like to provide more information on our debug environment and some
of the issues we're seeing...
We are running on a multi-CPU ARMv8 chipset. We are trying to step
individual CPU cores (not OS threads) and we continue to run into
problems that we were hoping you can shed some light on.
We issued the following GDB sequence to surface what we believe to be a
problem with the code or a problem with our expectations:
1. System starts off with all 8 ARM CPUs in the running state
2. ‘Scheduler-locking’ is set to ‘step’
a. This should allow future single steps to move the program counter
of the current CPU thread. We expect the other CPUs to remain halted.
3. CTRL-C in GDB halts all 8 CPUs
a. Thread status shows ‘external debug request’
4. Select thread (cpu) 4
5. Issue stepi to single step CPU4
a. Thread status shows ‘external debug request’ for all CPU threads
except CPU4 which shows ‘single step’ status
6. Select thread 1
7. Issue stepi to single step CPU1
a. Desired outcome is to have just CPU1 to single step and the other
CPUs to remain in their current halted state
b. Actual outcome is none of the CPUs actually get stepped
i. The code in function ‘hwthread_update_threads’ determines the
‘most interesting thread’ to be thread 4 (had status of ‘single step’)
and since this thread number does not match the current thread ID of 1,
a ‘fake’ step is performed. A ‘fake step’ does not step any of the CPUs
and this is the problem we are trying to address.
Questions:
1. Is there anything wrong with our desired outcome spelled out in step
7a above?
2. Why is there ever a need to do a ‘fake step’?
a. If the user wants to step a single CPU that was previously
halted, the hardware allows it to single step.
Thanks for any insights.
Dan Goehring
Ampere Computing
On 4/19/2019 1:06 PM, Daniel Goehring wrote:
> Tim,
>
> I reviewed the following patch and had to make a couple changes to get
> it to work in my environment (Ampere eMAG8180).
>
> 1. src/rtos/hwthread.c -> needed to remove the
> "assert(thread_list_size)". I'm hitting this assert in my environment.
>
> 2. src/server/gdb_server.c -> In the GDB client, when switching from one
> CPU core to another, the "rtos->current_threadid" variable gets
> correctly updated to reflect the new target CPU core, but the
> "rtos->current_thread" variable does not.
>
> I'm new to this project and don't understand the distinction between
> "current_threadid" and "current_thread". The end result is that on line
> 2799 in file gdb_server.c, when "current_thread" and "thread_id" don't
> match, "fake_step" gets enabled and I'm unable to step the newly select
> CPU core.
>
> I've added the above comments to the Gerrit review at
> http://openocd.zylin.com/#/c/5101/
>
> Dan Goehring
> Ampere Computing
>
> On 4/10/2019 3:34 PM, Tim Newsome wrote:
>> I just submitted my fix for this (along with a raft of other hwthread
>> tweaks) at http://openocd.zylin.com/#/c/5101/
>>
>> Tim
>>
>> On Wed, Apr 10, 2019 at 4:02 AM Matthias Welwarsky
>> <matthias.welwar...@sysgo.com <mailto:matthias.welwar...@sysgo.com>>
>> wrote:
>>
>> __
>>
>> On Dienstag, 9. April 2019 01:36:43 CEST Tim Newsome wrote:
>>
>> > 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?
>>
>> I'd prefer a fix for the clobbering of current_threadid inside
>> hwthread.c. There's another patch already submitted to that effect
>> and I think it's the correct solution. That patch has some other
>> weird stuff included that I'm not happy with so it's on hold until
>> the submitter cleans it up.
>>
>> Removing the thread update from the vcont support will have side
>> effects. I specifically put it there to circumvent a weird behaviour
>> I was seeing with rtos threads being not up to date at this point.
>> It should be resolved at a point but the fix for current_threadid
>> must go into hwthread.c anyway.
>>
>> BR,
>>
>> Matthias
>>
>> --
>> Mit freundlichen Grüßen/Best regards,
>>
>> Matthias Welwarsky
>>
>> Project Engineer
>>
>> SYSGO AG
>>
>> Office Mainz
>>
>> Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany
>>
>> Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
>>
>> VoIP: SIP:m...@sysgo.com <mailto:sip%3a...@sysgo.com>
>>
>> E-mail: matthias.welwar...@sysgo.com
>> <mailto:matthias.welwar...@sysgo.com> / Web: http://www.sysgo.com
>>
>>
>> _________________________________________________________________________________
>>
>>
>> Web: https://www.sysgo.com
>>
>> Blog: https://www.sysgo.com/blog
>>
>> Events: https://www.sysgo.com/events
>>
>> Newsletter: https://www.sysgo.com/newsletter
>>
>> _________________________________________________________________________________
>>
>>
>> Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066
>>
>> Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny (COO)
>>
>> Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon
>>
>> USt-Id-Nr./VAT-Id-No.: DE 149062328
>>
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
