clayborg added a comment.
This kind of stuff:
struct UserArea {
GPR gpr;
FPR fpr;
DBG dbg;
};
Was done on MacOSX systems because we have thread_get_state() and
thread_set_state() that take a flavor (enumeration) that specifies which
registers we should read. It also takes a pointer to a structure to fill in and
the size in bytes of that structure. For this reason, we ended up making a
UserArea that looked like above.
What you should be doing for your register context is duplicating the
structures that are in the system headers so that they can be compiled on a
system without these header files. So, this should be a duplication (don't use
the exact same names for the structure types):
typedef struct {
__gregset_t __gregs;
__greg_t _mc_tlsbase;
__fpregset_t __fpregs;
} mcontext_t;
Then if you have only one "read all registers" call that fills in all
registers, you should make any single register read kick off a single read of
all registers and mark all registers as valid. For MacOSX, a register read will
trigger a thread_get_state() and the GPR, FPU or DBG register flavor will be
used to fill in the register context for the thread and all registers one of
GPR, FPU, DBG will be marked as valid. If you have an API on your system that
allows each register to be read/written individually, you could do them
separately and mark each individual register valid after it is read. So this
really depends on your system interface for reading registers. There is usually
ptrace() calls for most unix based systems to read registers and you end up
reading them in sets.
The other thing to note, is that LLDB expects your registers numbers to start
at zero, and never have any register number gaps.
So as long as your changes adhere to what was said above, it is a good start.
Repository:
rL LLVM
http://reviews.llvm.org/D16508
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
