Thank you Ted for your comments.
On Mon, Sep 18, 2017 at 11:25 PM, Ted Woodward <ted.woodw...@codeaurora.org> wrote: > I recently added Hexagon Linux support to lldb-server; I did what Greg > suggested below - subclassed NativeRegisterContextLinux, like the other > architectures did. I also added the software breakpoint opcode to > NativeProcessLinux. After that, it was just a matter of getting the register > accessor functions in NativeRegisterContextLinux_hexagon.cpp correct. > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > >> -----Original Message----- >> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg >> Clayton via lldb-dev >> Sent: Monday, September 18, 2017 10:16 AM >> To: Ramana <ramana.venka...@gmail.com> >> Cc: lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] lldb_private::RegisterContext vs >> lldb_private::RegisterInfoInterface >> >> When supporting a new architecture, our preferred route is to modify lldb- >> server (a GDB server binary that supports native debugging) to support your >> architecture. Why? Because this gets you remote debugging for free. If you go >> this route, then you will subclass a lldb_private::NativeRegisterContext and >> that >> will get used by lldb-server (along with lldb_private::NativeProcessProtocol >> and >> lldb_private::NativeThreadProtocol). If you are adding a new architecture to >> Linux, then you will likely just need to subclass NativeRegisterContext. >> >> The other way to go is to subclass lldb_private::Process, >> lldb_private::Thread >> and lldb_private::RegisterContext. >> >> The nice thing about the lldb_private::Native* subclasses is that you only >> need >> to worry about native support. You can use #ifdef and use system header >> files, >> where as the non native route, those classes need to be able to debug >> remotely >> and you can't rely on system headers (lldb_private::Process, >> lldb_private::Thread and lldb_private::RegisterContext) since they can be >> compiled on any system for possibly local debugging (if current >> arch/vendor/os >> matches the current system) and remote (if you use lldb-server or another >> form for RPC). >> >> I would highly suggest getting going the lldb-server route as then you can >> use >> system header files that contain the definitions of the registers and you >> only >> need to worry about the native architecture. Linux uses ptrace and has much >> the the common code filtered out into correct classes (posix ptrace, linux >> specifics, and more. >> >> What architecture and os are you looking to support? >> >> Greg Clayton >> >> > On Sep 16, 2017, at 6:28 AM, Ramana <ramana.venka...@gmail.com> >> wrote: >> > >> > Thank you Greg for the detailed response. >> > >> > Can you please also shed some light on the NativeRegisterContext. When >> > do we need to subclass NativeRegisterContext and (how) are they >> > related to RegisterContext<OS>_<Arc It appears that not all >> > architectures having RegisterContext<OS>_<Arch> have sub classed >> > NativeRegisterContext. >> > >> > Regards, >> > Ramana >> > >> > On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton <clayb...@gmail.com> >> wrote: >> >> Seems like this class was added for testing. RegisterInfoInterface is a >> >> class >> that creates a common API for getting lldb_private::RegisterInfo structures. >> >> >> >> A RegisterContext<OS>_<Arch> class uses one of these to be able to create >> a buffer large enough to store all registers defined in the >> RegisterInfoInterface >> and will actually read/write there registers to/from the debugged process. >> RegisterContext also caches registers values so they don't get read multiple >> times when the process hasn't resumed. A RegisterContext subclass is needed >> for each architecture so we can dynamically tell LLDB what the registers look >> like for a given architecture. It also provides abstractions by letting each >> register define its registers numbers for Compilers, DWARF, and generic >> register numbers like PC, SP, FP, return address, and flags registers. This >> allows >> the generic part of LLDB to say "I need you to give me the PC register for >> this >> thread" and we don't need to know that the register is "eip" on x86, "rip" on >> x86_64, "r15" on ARM. RegisterContext classes can also determine how >> registers are read/written: one at a time, or "get all general purpose regs" >> and >> "get all FPU regs". So if someone asks a RegisterContext to read the PC, it >> might go read all GPR regs and then mark them all as valid in the register >> context buffer cache, so if someone subsequently asks for SP, it will be >> already >> cached. >> >> >> >> So RegisterInfoInterface defines a common way that many RegisterContext >> classes can inherit from in order to give out the lldb_private::RegisterInfo >> (which is required by all subclasses of RegisterContext) info for a register >> context, and RegisterContext is the one that actually will interface with the >> debugged process in order to read/write and cache those registers as >> efficiently as possible for the current program being debugged. >> >> >> >>> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev <lldb- >> d...@lists.llvm.org> wrote: >> >>> >> >>> Hi, >> >>> >> >>> When deriving RegisterContext<OS>_<Arch>, why some platforms >> >>> (Arch+OS) are deriving it from lldb_private::RegisterContext while >> >>> others are deriving from lldb_private::RegisterInfoInterface or in >> >>> other words how to decide on the base class to derive from between >> >>> those two and what are the implications? >> >>> >> >>> Thanks, >> >>> Ramana >> >>> _______________________________________________ >> >>> lldb-dev mailing list >> >>> lldb-dev@lists.llvm.org >> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev