On 22/07/16 07:51, Chris Johns wrote:
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the
CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
I would like this to be added to the formal _CPU_* port interface.
Without the marker the CPU will not able to support proper debugging.
I see the patch as correct.
To me this looks quite x86 specific.
This is the current target I am working on and the only one I have
looked at.
In order to move it to the CPU port area it should work on at least two
architectures from my point of view. The MIPS and LM32 use already a
_CPU_Context_switch_restore symbol. Is this similar to your x86 use
case? CPU port defines, functions, etc. should be documented in
"cpukit/score/cpu/no_cpu/rtems/score/cpu.h".
How would you set and use this
marker on ARM, PowerPC and SPARC for example?
I have not looked at the ARM in detail and would have to look up the
instructions but a guess would be 'L_restore:' in arm/cpu_asm.S. I do
not use the PowerPC or SPARC.
The requirement is the marker is the address to set the PC (IP) along
with the registers held in the TCB so a valid stack frame exists that
a DWARF unwind'er can unwind. It must exist somewhere in each system
or the context could not be restored.
Chris
Why can't you use the PC stored in the context along with the saved
registers? This is how the thread debug support works on ARM, PowerPC
and SPARC. Threads that did never run have an PC set to
_Thread_Handler(). They never called _CPU_Context_switch(), so your
marker would not work.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
