[Lldb-commits] [PATCH] D16508: NetBSD: Define initial RegisterContextNetBSD_x86_64

Sat Jan 23 08:50:32 PST 2016

tfiala added a comment.

In http://reviews.llvm.org/D16508#334424, @krytarowski wrote:

> I had difficulties with this code, as each platform implements it differently.

This class is one of the parts of the infrastructure needed to access registers for a given platform.  These show up on the LLDB side rather than the process monitor side.  So it should be LLDB using these to access register state, from any platform (e.g. used by LLDB running on perhaps Linux, debugging a process on NetBSD - this class would be used then).

(There are a set of classes called NativeRegisterContext* that are used in process monitoring directly on target, used by the process monitoring infrastructure as found in lldb-server - these are different and have different requirements).

Since this class needs to exist on any host OS, it will not include system headers to define these structures since, say in the scenario above, Linux wouldn't have the system headers necessary to define these structures for NetBSD.  So they need to be defined size-wise correct for any platform that would compile it.  (Otherwise it would be tempting to include the platform-specific system headers that already define all this data for you).

> What is DBG? What should be there?

These are the debug control registers:
https://en.wikipedia.org/wiki/X86_debug_register

> What is UserArea? What should be there?

This is the structure that the OS typically defines.  If you trace down the NetBSD existing debugging code headers, there will be something like this in there.  You want to mimic what this is as it should be the same memory layout as provided by NetBSD.  It almost certainly will look like this, since all these OSes for a given architecture generally have to represent the data however the underlying architecture allows them to expose it.

If you have trouble tracking that down, I can dig around some to find out what header it shows up in.

Repository:
  rL LLVM

http://reviews.llvm.org/D16508