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
