On 22/07/16 08:43, Sebastian Huber wrote:
On 22/07/16 08:34, Chris Johns wrote:
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_point, _is_fp,
_tls_area ) \
do { \
uint32_t _stack; \
\
(void) _is_fp; /* avoid warning for being unused */ \
if ( (_isr) ) (_the_context)->eflags =
CPU_EFLAGS_INTERRUPTS_OFF; \
else (_the_context)->eflags = CPU_EFLAGS_INTERRUPTS_ON; \
\
_stack = ((uint32_t)(_stack_base)) + (_size); \
_stack &= ~ (CPU_STACK_ALIGNMENT - 1); \
_stack -= 2*sizeof(proc_ptr*); /* see above for why we need to do
this */ \
*((proc_ptr *)(_stack)) = (_entry_point); \
(_the_context)->ebp = (void *) 0; \
(_the_context)->esp = (void *) _stack; \
} while (0)
The stack pointer is part of the context. If you retrieve the PC from
here it should work for all threads.
All threads on the i386 arch or all threads on all archs?
I would like to make this simpler for all archs. I do not mind if we
require something being added to each arch to do this but I would
like an interface somewhere and somehow.
I don't think that the thread context reconstruction can be done in an
architecture independent way. You have different register sets and
different ways to store the PC. For example on x86 the PC is on the
stack, on ARM you have Context_Control::register_lr, on PowerPC
ppc_context::lr which is embedded in Context_Control due to cache line
alignment, on SPARC you have Context_Control::o7, and so on.
I would rather provide a global function that provides the data for
your consumer (libunwind?) with a common interface for all
architectures and an architecture dependent implementation. The
debugger could call this function.
For the stack checker extension we have for example _CPU_Context_Get_SP().
--
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
