Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Greg Clayton via lldb-dev]

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  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_ It appears that not all architectures having
> RegisterContext_ have sub classed NativeRegisterContext.
> 
> Regards,
> Ramana
> 
> On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton  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_ 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  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> When deriving RegisterContext_, 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

Re: [lldb-dev] How can lldb debug a remote bare-metal platform?

[Greg Clayton via lldb-dev]

So when launching a GDB server there are two flows:

1 - When you connect you already have a process
2 - You will connect, then launch or attach to a process

LLDB tries to see if there is a process by sending the "qfThreadInfo" packet. 
As you see below, it responds with on character "l" which means  "end of the 
thread list". Since no thread IDs were returned, this makes LLDB believe that 
there is no process on the other end. So later when you try to say "process 
launch", it tries to send the "A" packet which tries to launch your program by 
sending the name of the process file to launch.

There was recently an OpenOCD patch to work around this with:

https://reviews.llvm.org/D37934 

This fixed this issue and also made it read both sets of registers via the XML 
target packets.

That should make things work, but it would be better if we modified the OpenOCD 
GDB server to respond with a thread ID when asked about its thread with the 
"qfThreadInfo" packet. Since it is a bare board connection, it should respond 
with "1" (one) to the "qfThreadInfo" packet followed by "l" to the next 
ThreadInfo packet (read GDB protocol docs on this.

Let me know if the patch mentioned above (which is already checked in) fixed 
your issues.



> On Sep 17, 2017, at 3:50 AM, cui bixiong via lldb-dev 
>  wrote:
> 
> Hi：
> 
> Currently I porting lldb for Hifive1 (riscv bare board) w/ openocd 
> 0.10.0, but it always show "error: Process must be launched."
> 
> I use GNU gdb to remote connect and debugging w/ the same openocd + elf, 
> it work OK.
>  
> I want to know how to launch Process in bare board?
> 
> thanks a lot!
> 
> $ lldb
> (lldb) log enable gdb-remote packets
> (lldb) target create Build3/riscv-hello.elf
> Current executable set to 'Build3/riscv-hello.elf' (riscv).
> (lldb) gdb-remote 172.27.113.29: 
> <   1> send ack packet: +
> history[1] tid=0x44c8 <   1> send packet: +
> <   1> read packet: +
> <  19> send SendPacketNoLock 2 packet: $QStartNoAckMode#b0
> <   1> read packet: +
> <   6> read packet: $OK#9a
> <   1> send ack packet: +
> <  41> send SendPacketNoLock 2 packet: 
> $qSupported:xmlRegisters=i386,arm,mips#12
> <  80> read packet: 
> $PacketSize=3fff;qXfer:memory-map:read+;qXfer:features:read-;QStartNoAckMode+#08
> <  26> send SendPacketNoLock 2 packet: $QThreadSuffixSupported#e4
> <   4> read packet: $#00
> <  27> send SendPacketNoLock 2 packet: $QListThreadsInStopReply#21
> <   4> read packet: $#00
> <  13> send SendPacketNoLock 2 packet: $qHostInfo#9b
> <   4> read packet: $#00
> <  10> send SendPacketNoLock 2 packet: $vCont?#49
> <   4> read packet: $#00
> <  27> send SendPacketNoLock 2 packet: $qVAttachOrWaitSupported#38
> <   4> read packet: $#00
> <  16> send SendPacketNoLock 2 packet: $qProcessInfo#dc
> <   4> read packet: $#00
> <   6> send SendPacketNoLock 2 packet: $qC#b4
> <   7> read packet: $QC0#c4
> <  16> send SendPacketNoLock 2 packet: $qfThreadInfo#bb
> <   5> read packet: $l#6c
> (lldb) thread list
> error: Process must be launched.
> (lldb) b main
> Breakpoint 1: where = riscv-hello.elf`main at hello.c:3, address = 0x20400230
> (lldb) thread continue
> error: invalid thread
> (lldb) process launch
> <  38> send SendPacketNoLock 2 packet: $QSetSTDIN:2f6465762f7074732f343238#b6
> <   4> read packet: $#00
> <  39> send SendPacketNoLock 2 packet: $QSetSTDOUT:2f6465762f7074732f343238#17
> <   4> read packet: $#00
> <  39> send SendPacketNoLock 2 packet: $QSetSTDERR:2f6465762f7074732f343238#08
> <   4> read packet: $#00
> <  21> send SendPacketNoLock 2 packet: $QSetDisableASLR:1#ce
> <   4> read packet: $#00
> <  23> send SendPacketNoLock 2 packet: $QSetDetachOnError:1#f8
> <   4> read packet: $#00
> <  21> send SendPacketNoLock 2 packet: $QLaunchArch:riscv#8b
> <   4> read packet: $#00
> <  33> send SendPacketNoLock 2 packet: $QEnvironment:BINARY_TYPE_HPC=#fd
> <   4> read packet: $#00
> < 115> send SendPacketNoLock 2 packet: 
> $A104,0,2f70726f6a2f6d746b31333836372f727369632d762f74657374696e672f4275696c64332f72697363762d68656c6c6f2e656c66#6c
> <   4> read packet: $#00
> error: process launch failed: 'A' packet returned an error: -1
> 
> 
> 
> Best Regards
> --cuibixiong
> ___
> 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

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ted Woodward via lldb-dev]

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 
> 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 
> 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_ > architectures having RegisterContext_ have sub classed
> > NativeRegisterContext.
> >
> > Regards,
> > Ramana
> >
> > On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton 
> 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_ 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  d...@lists.llvm.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> When deriving Reg

[lldb-dev] Reading eValueTypeLoadAddress with missing compiler type

[Leonardo Bianconi via lldb-dev]

Hi all!

I'm facing an issue with a value of lldb_private::Value::eValueTypeLoadAddress 
type, which cannot be loaded from memory because the compiler type was not 
filled.
That happens obtaining the fame base, which is based on "DW_OP_call_frame_cfa" 
case (DWARFExpression.cpp:2825).
After obtain the base frame, when resolving the value (Value.cpp:612), as the 
compiler type is invalid, the value is not read from memory, and the frame base 
keep as its address.

How can I solve this issue?
I looked in many files, and couldn't find how to fill the compiler type in the 
"DWARFExpression::Evaluate" method.


Thanks,
Leonardo Bianconi.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler type

[Greg Clayton via lldb-dev]

A DW_TAG_subprogram's usually has a DW_AT_frame_base DWARF expression that 
describes where the frame is. That evaluates to something and doesn't require 
any type. I am guessing you now have a variable that is relative to that frame 
base and that variable's type is not valid. This can be due to many reasons, 
most likely is the compiler may have redacted your type when trying to save 
space. Can you confirm this is what is happening?


> On Sep 18, 2017, at 12:25 PM, Leonardo Bianconi via lldb-dev 
>  wrote:
> 
> Hi all!
> 
> I'm facing an issue with a value of 
> lldb_private::Value::eValueTypeLoadAddress type, which cannot be loaded from 
> memory because the compiler type was not filled.
> That happens obtaining the fame base, which is based on 
> "DW_OP_call_frame_cfa" case (DWARFExpression.cpp:2825).
> After obtain the base frame, when resolving the value (Value.cpp:612), as the 
> compiler type is invalid, the value is not read from memory, and the frame 
> base keep as its address.
> 
> How can I solve this issue?
> I looked in many files, and couldn't find how to fill the compiler type in 
> the "DWARFExpression::Evaluate" method.
> 
> 
> Thanks,
> Leonardo Bianconi.
> ___
> 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

Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler type

[Greg Clayton via lldb-dev]

If you have the binary and the function that this is happening in and can share 
the binary that contains debug info and also share which file and function and 
variable is causing the issue, I might be able to tell you why this is 
happening.

Greg

> On Sep 18, 2017, at 1:23 PM, Greg Clayton  wrote:
> 
> A DW_TAG_subprogram's usually has a DW_AT_frame_base DWARF expression that 
> describes where the frame is. That evaluates to something and doesn't require 
> any type. I am guessing you now have a variable that is relative to that 
> frame base and that variable's type is not valid. This can be due to many 
> reasons, most likely is the compiler may have redacted your type when trying 
> to save space. Can you confirm this is what is happening?
> 
> 
>> On Sep 18, 2017, at 12:25 PM, Leonardo Bianconi via lldb-dev 
>>  wrote:
>> 
>> Hi all!
>> 
>> I'm facing an issue with a value of 
>> lldb_private::Value::eValueTypeLoadAddress type, which cannot be loaded from 
>> memory because the compiler type was not filled.
>> That happens obtaining the fame base, which is based on 
>> "DW_OP_call_frame_cfa" case (DWARFExpression.cpp:2825).
>> After obtain the base frame, when resolving the value (Value.cpp:612), as 
>> the compiler type is invalid, the value is not read from memory, and the 
>> frame base keep as its address.
>> 
>> How can I solve this issue?
>> I looked in many files, and couldn't find how to fill the compiler type in 
>> the "DWARFExpression::Evaluate" method.
>> 
>> 
>> Thanks,
>> Leonardo Bianconi.
>> ___
>> 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

Re: [lldb-dev] How can lldb debug a remote bare-metal platform?

[cui bixiong via lldb-dev]

Hi Greg:

It's worked, thank you!, but I still have a question, in GNU-GDB which
provide `load` command to download a ELF file into bare-board, in LLDB
support those features? should I dump a binary file and use lldb "target
module load" to replace 'load' command?

​Best Regards
--cuibixiong​


2017-09-18 23:53 GMT+08:00 Greg Clayton :

> So when launching a GDB server there are two flows:
>
> 1 - When you connect you already have a process
> 2 - You will connect, then launch or attach to a process
>
> LLDB tries to see if there is a process by sending the "qfThreadInfo"
> packet. As you see below, it responds with on character "l" which means
>  "end of the thread list". Since no thread IDs were returned, this makes
> LLDB believe that there is no process on the other end. So later when you
> try to say "process launch", it tries to send the "A" packet which tries to
> launch your program by sending the name of the process file to launch.
>
> There was recently an OpenOCD patch to work around this with:
>
> https://reviews.llvm.org/D37934
>
> This fixed this issue and also made it read both sets of registers via the
> XML target packets.
>
> That should make things work, but it would be better if we modified the
> OpenOCD GDB server to respond with a thread ID when asked about its thread
> with the "qfThreadInfo" packet. Since it is a bare board connection, it
> should respond with "1" (one) to the "qfThreadInfo" packet followed by "l"
> to the next ThreadInfo packet (read GDB protocol docs on this.
>
> Let me know if the patch mentioned above (which is already checked in)
> fixed your issues.
>
>
>
> On Sep 17, 2017, at 3:50 AM, cui bixiong via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi：
>
> Currently I porting lldb for Hifive1 (riscv bare board) w/ openocd
> 0.10.0, but it always show "error: Process must be launched."
>
> I use GNU gdb to remote connect and debugging w/ the same openocd +
> elf, it work OK.
>
> I want to know how to launch Process in bare board?
>
> thanks a lot!
>
> $ lldb
> (lldb) log enable gdb-remote packets
> (lldb) target create Build3/riscv-hello.elf
> Current executable set to 'Build3/riscv-hello.elf' (riscv).
> (lldb) gdb-remote 172.27.113.29:
> <   1> send ack packet: +
> history[1] tid=0x44c8 <   1> send packet: +
> <   1> read packet: +
> <  19> send SendPacketNoLock 2 packet: $QStartNoAckMode#b0
> <   1> read packet: +
> <   6> read packet: $OK#9a
> <   1> send ack packet: +
> <  41> send SendPacketNoLock 2 packet: $qSupported:xmlRegisters=i386,
> arm,mips#12
> <  80> read packet: $PacketSize=3fff;qXfer:memory-
> map:read+;qXfer:features:read-;QStartNoAckMode+#08
> <  26> send SendPacketNoLock 2 packet: $QThreadSuffixSupported#e4
> <   4> read packet: $#00
> <  27> send SendPacketNoLock 2 packet: $QListThreadsInStopReply#21
> <   4> read packet: $#00
> <  13> send SendPacketNoLock 2 packet: $qHostInfo#9b
> <   4> read packet: $#00
> <  10> send SendPacketNoLock 2 packet: $vCont?#49
> <   4> read packet: $#00
> <  27> send SendPacketNoLock 2 packet: $qVAttachOrWaitSupported#38
> <   4> read packet: $#00
> <  16> send SendPacketNoLock 2 packet: $qProcessInfo#dc
> <   4> read packet: $#00
> <   6> send SendPacketNoLock 2 packet: $qC#b4
> <   7> read packet: $QC0#c4
> <  16> send SendPacketNoLock 2 packet: $qfThreadInfo#bb
> <   5> read packet: $l#6c
> (lldb) thread list
> error: Process must be launched.
> (lldb) b main
> Breakpoint 1: where = riscv-hello.elf`main at hello.c:3, address =
> 0x20400230
> (lldb) thread continue
> error: invalid thread
> (lldb) process launch
> <  38> send SendPacketNoLock 2 packet: $QSetSTDIN:2f6465762f7074732f3
> 43238#b6
> <   4> read packet: $#00
> <  39> send SendPacketNoLock 2 packet: $QSetSTDOUT:2f6465762f7074732f
> 343238#17
> <   4> read packet: $#00
> <  39> send SendPacketNoLock 2 packet: $QSetSTDERR:2f6465762f7074732f
> 343238#08
> <   4> read packet: $#00
> <  21> send SendPacketNoLock 2 packet: $QSetDisableASLR:1#ce
> <   4> read packet: $#00
> <  23> send SendPacketNoLock 2 packet: $QSetDetachOnError:1#f8
> <   4> read packet: $#00
> <  21> send SendPacketNoLock 2 packet: $QLaunchArch:riscv#8b
> <   4> read packet: $#00
> <  33> send SendPacketNoLock 2 packet: $QEnvironment:BINARY_TYPE_HPC=#fd
> <   4> read packet: $#00
> < 115> send SendPacketNoLock 2 packet: $A104,0,2f70726f6a2f6d746b3133
> 3836372f727369632d762f74657374696e672f4275696c64332f72697363
> 762d68656c6c6f2e656c66#6c
> <   4> read packet: $#00
> error: process launch failed: 'A' packet returned an error: -1
>
>
>
> Best Regards
> --cuibixiong
> ___
> 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