On 22/07/16 08:52, Chris Johns wrote:
On 22/07/2016 16:44, Sebastian Huber wrote:
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.
Sorry, I was meaning just a way to get the PC.
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.
The consumer is a thread aware TCP gdb server running in RTEMS.
For the stack checker extension we have for example
_CPU_Context_Get_SP().
_CPU_Context_Get_PC() ?
I would like this to be localised to the CPU implementation and
something that is figured out when a new port is done.
Yes, I think a _CPU_Context_Get_PC() would be the right way to do this.
--
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