date:20170919

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

2017-09-19 Thread Ramana via lldb-dev

Thank you Ted for your comments.

On Mon, Sep 18, 2017 at 11:25 PM, Ted Woodward
 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 
>> 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 thos

Re: [lldb-dev] Prologue instructions having line information

2017-09-19 Thread Carlos Alberto Enciso via lldb-dev

I have been trying to build LLDB on Windows (7) and after couple of days, I
managed to have a successfull build.

These are my findings:

1) Follow the instructions from

https://lldb.llvm.org/build.html

2) With Python 2.7, the cmake process fails, as it can't locate the
following files:

python_d.exe
python27_d.lib
python27_d.dll

3) During the installation of Python 3.6, make sure to include the Debug
Symbols, which are the missing files from (2).

4) Set the following environment variables:

PYTHONHOME  -> Directory where Python 3.6 is installed
PYTHONPATH=%PYTHONHOME%\Lib <- Lib
PYTHON_INCLUDE=%PYTHONHOME%\Include
PYTHON_LIB=%PYTHONHOME%\Libs

5) SWIG

Download the distribution specified in the LLDB documentation:

http://prdownloads.sourceforge.net/swig/swigwin-3.0.12.zip

Unzipp the whole contents and add an environment variable like

SWIG_DIR  -> Directory where the zip file was unzipped.

It seems that the only way for cmake to pick up some of the previous
environment variables, is to specifiy them as parameters in the command
line.

At the end, with the following command line I managed to get a successful
build.

cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
-DSWIG_DIR=C:\ProgramData\SWIG  -DPYTHON_HOME=C:\ProgramData\Python36
-DPYTHON_EXECUTABLE=C:\ProgramData\Python36\python.exe ..\llvm

You can add the following options if needed:

-DLLDB_TEST_DEBUG_TEST_CRASHES=1
-DLLDB_RELOCATABLE_PYTHON=1
-DLLDB_TEST_COMPILER=

My next tasks are:

try: check-all, check_lldb configurations.

I will post my findings.

Hope this help.



On Thu, Sep 14, 2017 at 6:10 PM, John Lindal  wrote:

> Which platform are you building on?  I have been unable to build on OS X.
>
> John
>
>
> On Sep 14, 2017, at 10:08 AM, Carlos Alberto Enciso via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi Tamas,
>
> Thanks very much for your reply and the useful information.
>
> In order to properly test my changes (I have another Debug Information
> ready for submission) I would like be able to build LLDB on my local
> machine. Once I reach that point, I will follow the process you described
> (compile calling.cpp) and I would let you know my progress.
>
> Best regards,
> Carlos
>
> On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer  > wrote:
>
>> Hi Carlos,
>>
>> Thank your for looking into the LLDB failure. I looked into it briefly
>> and the issue is that we have have 2 function f and g where g is inlined
>> into f as the first call and this causes the first non-prologue line entry
>> of f to be inside the address range of g what means that when we step info
>> f from outside we will end up inside g instead. Previously the first line
>> entry for f matched with the start address of the inlined copy of g where
>> LLDB was able to handle the stepping properly.
>>
>> For the concrete example you should compile https://github.com/llv
>> m-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/
>> packages/Python/lldbsuite/test/functionalities/inline-steppi
>> ng/calling.cpp with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0
>> -std=c++11 -g -O0 -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then
>> observe that caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the
>> inlined inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the
>> first line entry after "Set prologue_end to true" is at 0x8048796 while
>> previously it was at 0x8048793.
>>
>> Tamas
>>
>> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I have been working on a compiler issue, where instructions associated
>>> to the function prolog are assigned line information, causing the debugger
>>> to show incorrectly the beginning of the function body.
>>>
>>> For a full description, please see:
>>>
>>> https://reviews.llvm.org/D37625
>>> https://reviews.llvm.org/rL313047
>>>
>>> The submitted patch caused some LLDB tests to fail. I have attached the
>>> log failure.
>>>
>>> I have no knowledge about the test framework used by LLDB.
>>>
>>> What is the best way to proceed in this case?
>>>
>>> Thanks very much for your feedback.
>>>
>>> Carlos Enciso
>>>
>>>
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
>
> 
> Virus-free. www.avg.com
> 
> ___
> 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

2017-09-19 Thread Ramana via lldb-dev

Thank you so much Greg for your comments.

> What architecture and os are you looking to support?

The OS is Linux and the primary use scenario is remote debugging.
Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html
is what I am trying to achieve and unfortunately that query did not
get much attention of the members.

Thanks,
Ramana

On Mon, Sep 18, 2017 at 8:46 PM, Greg Clayton  wrote:
> 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
 ___

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

2017-09-19 Thread Leonardo Bianconi via lldb-dev

Some more details:

I'm part of the team that is working in LLDB to enable PPC64le architecture, so 
I'm running my test in a Power8 machine.
When compiling the code with clang, it works, the issue happen when compiling 
with gcc, which generates a different debug information content.

Talking a bit about the power stack frame, it is organized this way:

Suppose that you have two functions a() and b() and a calls b, then the frames 
will be like this:

high address
+-+
|  ...| // frame of a
|  ...|
|  ...|
|  ...|
|  ...|
|   back chain|  // r31 and r1 points here when running function a
+-+
|  ...| // frame of b
|variable address |
|  ...|
|  ...|
|  ...|
|   back chain|  // r31 and r1 points here when running function b
+-+
low address

The debug information related to find the variable with clang is:
<2><6ce>: Abbrev Number: 27 (DW_TAG_variable)
<6cf>   DW_AT_location: 3 byte block: 91 f0 0   (DW_OP_fbreg: 112)
<6d3>   DW_AT_name: (indirect string, offset: 0x1cf): a
<6d7>   DW_AT_decl_file   : 5
<6d8>   DW_AT_decl_line   : 6
<6d9>   DW_AT_type: <0x1bf>
 <2><6dd>: Abbrev Number: 0
 <1><6de>: Abbrev Number: 0
 <1><6b5>: Abbrev Number: 26 (DW_TAG_subprogram)
<6b6>   DW_AT_low_pc  : 0x1630
<6be>   DW_AT_high_pc : 0x88
<6c2>   DW_AT_frame_base  : 1 byte block: 6f(DW_OP_reg31 (r31))
<6c4>   DW_AT_name: (indirect string, offset: 0x1ca): main
<6c8>   DW_AT_decl_file   : 5
<6c9>   DW_AT_decl_line   : 5
<6ca>   DW_AT_type: <0x1bf>
<6ce>   DW_AT_external: 1

Which uses the r31 (DW_OP_reg31) and a positive offset (112) to find it, which 
is ok, as it does not need to read the memory using the address in the r31 
register.

The issue happen when using the debug information generated by gcc, which is:
  <2><9e>: Abbrev Number: 5 (DW_TAG_variable)
<9f>   DW_AT_name: a
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 6
   DW_AT_type: <0x3b>
   DW_AT_location: 2 byte block: 91 5c  (DW_OP_fbreg: -36)
 <1><81>: Abbrev Number: 4 (DW_TAG_subprogram)
<82>   DW_AT_external: 1
<82>   DW_AT_name: (indirect string, offset: 0xe): main
<86>   DW_AT_decl_file   : 1
<87>   DW_AT_decl_line   : 5
<88>   DW_AT_type: <0x3b>
<8c>   DW_AT_low_pc  : 0x840
<94>   DW_AT_high_pc : 0xf8
<9c>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<9e>   DW_AT_GNU_all_tail_call_sites: 1

Here, it says to use the "DW_OP_call_frame_cfa", that is correctly executed in 
the LLDB, obtaining the content of r31 and setting it as " 
lldb_private::Value::eValueTypeLoadAddress", which means the data it is looking 
for is located in the address obtained in the r31, and it need to be read from 
memory. If the address was correctly read, it would point to the back chain of 
the previous frame, and the variable would be found, as the offset is negative 
(-36), so ("previous back chain address" - 36) is the correct variable address.

My code is very simple:
=
#include 
 #include 

 int main(void) {
int a = 2;
printf("a address: %p \n", (void*)&a);
printf("a = %d \n", a);
return 0;
 }
=

And I'm using the commands:
gcc -O0 -ggdb stest.cpp (gcc  version 5.4.1 20170304)
clang -O0 -ggdb stest.cpp


I think it is not related with the variable type, right?

Thanks!



> -Original Message-
> From: Greg Clayton [mailto:clayb...@gmail.com]
> Sent: segunda-feira, 18 de setembro de 2017 17:24
> To: Leonardo Bianconi 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler
> type
> 
> 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  d...@lists.llvm.org> 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

Re: [lldb-dev] Prologue instructions having line information

2017-09-19 Thread Carlos Alberto Enciso via lldb-dev

Results from 'check-all' project:
-

Additional requirement: the regression tests requires the python 'psutil'
module.

There is a common error when trying to build 'check-all' project. One of
the instances can be seen on:

llvm\projects\compiler-rt\test\lit.common.cfg:34

# Setup clang binary.
compiler_path = getattr(config, 'clang', None)
if (not compiler_path) or (not os.path.exists(compiler_path)):
  lit_config.fatal("Can't find compiler on path %r" % compiler_path)

that generates the following error:

"Can't find compiler on path "

with pathname pointing to the required clang.exe, but having the
$(Configuration) string. Basically, that cmake attribute not being
expanded. Is was building the 'Release' configuration.

Using the option -DLLVM_BUILD_RUNTIME=OFF, seems to fix the problems. But I
do not know about any side effects on the LLDB tests.

Thanks,
Carlos

On Tue, Sep 19, 2017 at 11:19 AM, Carlos Alberto Enciso <
international.phan...@gmail.com> wrote:

> I have been trying to build LLDB on Windows (7) and after couple of days,
> I managed to have a successfull build.
>
> These are my findings:
>
> 1) Follow the instructions from
>
> https://lldb.llvm.org/build.html
>
> 2) With Python 2.7, the cmake process fails, as it can't locate the
> following files:
>
> python_d.exe
> python27_d.lib
> python27_d.dll
>
> 3) During the installation of Python 3.6, make sure to include the Debug
> Symbols, which are the missing files from (2).
>
> 4) Set the following environment variables:
>
> PYTHONHOME  -> Directory where Python 3.6 is installed
> PYTHONPATH=%PYTHONHOME%\Lib <- Lib
> PYTHON_INCLUDE=%PYTHONHOME%\Include
> PYTHON_LIB=%PYTHONHOME%\Libs
>
> 5) SWIG
>
> Download the distribution specified in the LLDB documentation:
>
> http://prdownloads.sourceforge.net/swig/swigwin-3.0.12.zip
>
> Unzipp the whole contents and add an environment variable like
>
> SWIG_DIR  -> Directory where the zip file was unzipped.
>
> It seems that the only way for cmake to pick up some of the previous
> environment variables, is to specifiy them as parameters in the command
> line.
>
> At the end, with the following command line I managed to get a successful
> build.
>
> cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
> -DSWIG_DIR=C:\ProgramData\SWIG  -DPYTHON_HOME=C:\ProgramData\Python36
> -DPYTHON_EXECUTABLE=C:\ProgramData\Python36\python.exe ..\llvm
>
> You can add the following options if needed:
>
> -DLLDB_TEST_DEBUG_TEST_CRASHES=1
> -DLLDB_RELOCATABLE_PYTHON=1
> -DLLDB_TEST_COMPILER=
>
> My next tasks are:
>
> try: check-all, check_lldb configurations.
>
> I will post my findings.
>
> Hope this help.
>
>
>
> On Thu, Sep 14, 2017 at 6:10 PM, John Lindal  wrote:
>
>> Which platform are you building on?  I have been unable to build on OS X.
>>
>> John
>>
>>
>> On Sep 14, 2017, at 10:08 AM, Carlos Alberto Enciso via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Hi Tamas,
>>
>> Thanks very much for your reply and the useful information.
>>
>> In order to properly test my changes (I have another Debug Information
>> ready for submission) I would like be able to build LLDB on my local
>> machine. Once I reach that point, I will follow the process you described
>> (compile calling.cpp) and I would let you know my progress.
>>
>> Best regards,
>> Carlos
>>
>> On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer > .com> wrote:
>>
>>> Hi Carlos,
>>>
>>> Thank your for looking into the LLDB failure. I looked into it briefly
>>> and the issue is that we have have 2 function f and g where g is inlined
>>> into f as the first call and this causes the first non-prologue line entry
>>> of f to be inside the address range of g what means that when we step info
>>> f from outside we will end up inside g instead. Previously the first line
>>> entry for f matched with the start address of the inlined copy of g where
>>> LLDB was able to handle the stepping properly.
>>>
>>> For the concrete example you should compile https://github.com/llv
>>> m-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/
>>> packages/Python/lldbsuite/test/functionalities/inline-steppi
>>> ng/calling.cpp with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0
>>> -std=c++11 -g -O0 -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then
>>> observe that caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the
>>> inlined inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the
>>> first line entry after "Set prologue_end to true" is at 0x8048796 while
>>> previously it was at 0x8048793.
>>>
>>> Tamas
>>>
>>> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Hi,

 I have been working on a compiler issue, where instructions associated
 to the function prolog are assigned line information, causing the debugger
 to show incorrectly the beginning of the function body.

 For a full desc

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

2017-09-19 Thread Greg Clayton via lldb-dev

Load like "target modules load" has a --load option that will load the ELF into 
memory. I think it should do what you want. Let me know how it goes.

Greg Clayton

> On Sep 18, 2017, at 9:58 PM, cui bixiong  wrote:
> 
> 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 
>> mailto: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: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 err

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

2017-09-19 Thread Greg Clayton via lldb-dev

> On Sep 19, 2017, at 3:32 AM, Ramana  wrote:
> 
> Thank you so much Greg for your comments.
> 
>> What architecture and os are you looking to support?
> 
> The OS is Linux and the primary use scenario is remote debugging.
> Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html
> is what I am trying to achieve and unfortunately that query did not
> get much attention of the members.
> 

Sorry about missing that. I will attempt to address this now:

> I have to implement a debugger for our HW which comprises of CPU+GPU where
> the GPU is coded in OpenCL and is accelerated through OpenVX API in C++
> application which runs on CPU. Our requirement is we should be able to
> debug the code running on both CPU and GPU simultaneously with in the same
> LLDB debug session.

Interesting. There are two ways to accomplish this:
1 - Treat the CPU as one target and the GPU as another.
2 - Treat the CPU and GPU as one target

There are tricky areas for both, but for sanity I would suggest options #1. 

The tricky things with solution #1 is how to manage switching the targets 
between the CPU and GPU when events happen (CPU stops, or GPU stops while the 
other is running or already stopped). We don't have any formal "cooperative 
targets" yet, but we know they will exist in the future (client/server, vm 
code/vm debug of vm code, etc) so we will be happy to assist with questions if 
and when you get there.

Option #2 would be tricky as this would be the first target that has multiple 
architectures within one process. IF the CPU and GPU be be controlled 
separately, then I would go with option #1 as LLDB currently always stops all 
threads in a process when any thread stops. You would also need to implement 
different register contexts for each thread within such a target. It hasn't 
been done yet, other than through the OS plug-ins that can provide extra 
threads to show in case you are doing some sort of user space threading.

GPU debugging is tricky since they usually don't have a kernel or anything 
running on the hardware. Many examples I have seen so far will set a breakpoint 
in the program at some point by compiling the code with a breakpoint inserted, 
run to that breakpoint, and then if the user wants to continue, you recompile 
with breakpoints set at a later place and re-run the entire program again. Is 
your GPU any different? Since they will be used in an OpenCL context maybe your 
solution is better? We also had discussions on how to represent the various 
"waves" or sets of cores running the same program on the GPU. The easiest 
solution is to make one thread per distinct core on the GPU. The harder way 
would be to treat a thread as a collection of multiple cores and each variable 
value now can have one value per core. 

We also discussed how to single step in a GPU program. Since multiple cores on 
the GPU are concurrently running the same program, there was discussion on how 
single stepping would work. If you are stepping and run into an if/then 
statement, do you walk through the if and the else at all times? One GPU 
professional was saying this is how GPU folks would want to see single stepping 
happen. So I think there is a lot of stuff we need to think about when 
debugging GPUs in general.
> 
> Looking at the mailing list archive I see that there were discussions about
> this feature in LLDB here
> http://lists.llvm.org/pipermail/lldb-dev/2014-August/005074.html. 
> 
> 
> What is the present status i.e. what works today and what is to be improved
> of simultaneous multiple target debugging support in LLDB? Were the changes
> contributed to LLDB mainstream?

So we currently have no cooperative targets in LLDB. This will be the first. We 
will need to discuss how hand off between the targets will occur and many other 
aspects. We will be sure to comment when and if you get to this point.
> 
> How can I access the material for http://llvm.org/devmtg/2014-10/#bof5 
> 
> (Future directions and features for LLDB)
Over the years we have talked about this, but it never really got into any real 
amount of detail and I don't think the BoF notes will help you much.
> Appreciate any help/guidance provided on the same.
I do believe approach #1 will work the best. The easiest thing you can do is to 
insulate LLDB from the GPU by putting it behind a GDB server boundary. Then we 
need to really figure out how we want to do GPU debugging. 
Hopefully this filled in your missing answers. Let me know what questions you 
have.

Greg

> Thanks,
> Ramana
> 
> On Mon, Sep 18, 2017 at 8:46 PM, Greg Clayton  wrote:
>> 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 
>> lld

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

2017-09-19 Thread Greg Clayton via lldb-dev


> On Sep 19, 2017, at 4:10 AM, Leonardo Bianconi 
>  wrote:
> 
> Some more details:
> 
> I'm part of the team that is working in LLDB to enable PPC64le architecture, 
> so I'm running my test in a Power8 machine.
> When compiling the code with clang, it works, the issue happen when compiling 
> with gcc, which generates a different debug information content.
> 
> Talking a bit about the power stack frame, it is organized this way:
> 
> Suppose that you have two functions a() and b() and a calls b, then the 
> frames will be like this:
> 
> high address
> +-+
> |  ...| // frame of a
> |  ...|
> |  ...|
> |  ...|
> |  ...|
> |   back chain|  // r31 and r1 points here when running function a
> +-+
> |  ...| // frame of b
> |variable address |
> |  ...|
> |  ...|
> |  ...|
> |   back chain|  // r31 and r1 points here when running function b
> +-+
> low address
> 
> The debug information related to find the variable with clang is:
> <2><6ce>: Abbrev Number: 27 (DW_TAG_variable)
><6cf>   DW_AT_location: 3 byte block: 91 f0 0   (DW_OP_fbreg: 112)
><6d3>   DW_AT_name: (indirect string, offset: 0x1cf): a
><6d7>   DW_AT_decl_file   : 5
><6d8>   DW_AT_decl_line   : 6
><6d9>   DW_AT_type: <0x1bf>
> <2><6dd>: Abbrev Number: 0
> <1><6de>: Abbrev Number: 0
> <1><6b5>: Abbrev Number: 26 (DW_TAG_subprogram)
><6b6>   DW_AT_low_pc  : 0x1630
><6be>   DW_AT_high_pc : 0x88
><6c2>   DW_AT_frame_base  : 1 byte block: 6f(DW_OP_reg31 (r31))
><6c4>   DW_AT_name: (indirect string, offset: 0x1ca): main
><6c8>   DW_AT_decl_file   : 5
><6c9>   DW_AT_decl_line   : 5
><6ca>   DW_AT_type: <0x1bf>
><6ce>   DW_AT_external: 1
> 
> Which uses the r31 (DW_OP_reg31) and a positive offset (112) to find it, 
> which is ok, as it does not need to read the memory using the address in the 
> r31 register.
> 
> The issue happen when using the debug information generated by gcc, which is:
>  <2><9e>: Abbrev Number: 5 (DW_TAG_variable)
><9f>   DW_AT_name: a
>   DW_AT_decl_file   : 1
>   DW_AT_decl_line   : 6
>   DW_AT_type: <0x3b>
>   DW_AT_location: 2 byte block: 91 5c  (DW_OP_fbreg: -36)
> <1><81>: Abbrev Number: 4 (DW_TAG_subprogram)
><82>   DW_AT_external: 1
><82>   DW_AT_name: (indirect string, offset: 0xe): main
><86>   DW_AT_decl_file   : 1
><87>   DW_AT_decl_line   : 5
><88>   DW_AT_type: <0x3b>
><8c>   DW_AT_low_pc  : 0x840
><94>   DW_AT_high_pc : 0xf8
><9c>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
><9e>   DW_AT_GNU_all_tail_call_sites: 1
> 
> Here, it says to use the "DW_OP_call_frame_cfa", that is correctly executed 
> in the LLDB, obtaining the content of r31 and setting it as " 
> lldb_private::Value::eValueTypeLoadAddress", which means the data it is 
> looking for is located in the address obtained in the r31, and it need to be 
> read from memory. If the address was correctly read, it would point to the 
> back chain of the previous frame, and the variable would be found, as the 
> offset is negative (-36), so ("previous back chain address" - 36) is the 
> correct variable address.
> 
> My code is very simple:
> =
> #include 
> #include 
> 
> int main(void) {
>int a = 2;
>printf("a address: %p \n", (void*)&a);
>printf("a = %d \n", a);
>return 0;
> }
> =
> 
> And I'm using the commands:
> gcc -O0 -ggdb stest.cpp (gcc  version 5.4.1 20170304)
> clang -O0 -ggdb stest.cpp
> 
> 
> I think it is not related with the variable type, right?

It might be, can you show the DWARF for the 0x3b type? This was in your GCC 
variable's DWARF:

>   DW_AT_type: <0x3b>

There should be nothing wrong with that as long as LLDB is correctly setting 
r31 into the expression stack in response to the DW_OP_call_frame_cfa opcode. 
It should grab r31 - 36 and push the result onto the expression stack with 
eValueTypeLoadAddress as the type. Then we just need to read the type from 
memory. Since the type is so simple (int), I don't see the type failing here. I 
am guessing the DW_OP_call_frame_cfa is messing up the expression somehow. Can 
you step through and make sure that "r31 - 36" is correctly being pushed onto 
the expression stack?
 
> 
> Thanks!
> 
> 
> 
>> -Original Message-
>> From: Greg Clayton [mailto:clayb...@gmail.com]
>> Sent: segunda-feira, 18 de setembro de 2017 17:24
>> To: Leonardo Bianconi 
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler
>> type
>> 
>> If you have the binary and the function that this is happening in and can 
>> share the
>> binary that contains debug info

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

2017-09-19 Thread Leonardo Bianconi via lldb-dev



> -Original Message-
> From: Greg Clayton [mailto:clayb...@gmail.com]
> Sent: terça-feira, 19 de setembro de 2017 12:33
> To: Leonardo Bianconi 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler
> type
> 
> 
> > On Sep 19, 2017, at 4:10 AM, Leonardo Bianconi
>  wrote:
> >
> > Some more details:
> >
> > I'm part of the team that is working in LLDB to enable PPC64le 
> > architecture, so
> I'm running my test in a Power8 machine.
> > When compiling the code with clang, it works, the issue happen when 
> > compiling
> with gcc, which generates a different debug information content.
> >
> > Talking a bit about the power stack frame, it is organized this way:
> >
> > Suppose that you have two functions a() and b() and a calls b, then the 
> > frames
> will be like this:
> >
> > high address
> > +-+
> > |  ...| // frame of a
> > |  ...|
> > |  ...|
> > |  ...|
> > |  ...|
> > |   back chain|  // r31 and r1 points here when running function a
> > +-+
> > |  ...| // frame of b
> > |variable address |
> > |  ...|
> > |  ...|
> > |  ...|
> > |   back chain|  // r31 and r1 points here when running function b
> > +-+
> > low address
> >
> > The debug information related to find the variable with clang is:
> > <2><6ce>: Abbrev Number: 27 (DW_TAG_variable)
> ><6cf>   DW_AT_location: 3 byte block: 91 f0 0   (DW_OP_fbreg: 112)
> ><6d3>   DW_AT_name: (indirect string, offset: 0x1cf): a
> ><6d7>   DW_AT_decl_file   : 5
> ><6d8>   DW_AT_decl_line   : 6
> ><6d9>   DW_AT_type: <0x1bf>
> > <2><6dd>: Abbrev Number: 0
> > <1><6de>: Abbrev Number: 0
> > <1><6b5>: Abbrev Number: 26 (DW_TAG_subprogram)
> ><6b6>   DW_AT_low_pc  : 0x1630
> ><6be>   DW_AT_high_pc : 0x88
> ><6c2>   DW_AT_frame_base  : 1 byte block: 6f(DW_OP_reg31 (r31))
> ><6c4>   DW_AT_name: (indirect string, offset: 0x1ca): main
> ><6c8>   DW_AT_decl_file   : 5
> ><6c9>   DW_AT_decl_line   : 5
> ><6ca>   DW_AT_type: <0x1bf>
> ><6ce>   DW_AT_external: 1
> >
> > Which uses the r31 (DW_OP_reg31) and a positive offset (112) to find it, 
> > which
> is ok, as it does not need to read the memory using the address in the r31
> register.
> >
> > The issue happen when using the debug information generated by gcc, which
> is:
> >  <2><9e>: Abbrev Number: 5 (DW_TAG_variable)
> ><9f>   DW_AT_name: a
> >   DW_AT_decl_file   : 1
> >   DW_AT_decl_line   : 6
> >   DW_AT_type: <0x3b>
> >   DW_AT_location: 2 byte block: 91 5c  (DW_OP_fbreg: -36)
> > <1><81>: Abbrev Number: 4 (DW_TAG_subprogram)
> ><82>   DW_AT_external: 1
> ><82>   DW_AT_name: (indirect string, offset: 0xe): main
> ><86>   DW_AT_decl_file   : 1
> ><87>   DW_AT_decl_line   : 5
> ><88>   DW_AT_type: <0x3b>
> ><8c>   DW_AT_low_pc  : 0x840
> ><94>   DW_AT_high_pc : 0xf8
> ><9c>   DW_AT_frame_base  : 1 byte block: 9c 
> > (DW_OP_call_frame_cfa)
> ><9e>   DW_AT_GNU_all_tail_call_sites: 1
> >
> > Here, it says to use the "DW_OP_call_frame_cfa", that is correctly executed 
> > in
> the LLDB, obtaining the content of r31 and setting it as "
> lldb_private::Value::eValueTypeLoadAddress", which means the data it is 
> looking
> for is located in the address obtained in the r31, and it need to be read from
> memory. If the address was correctly read, it would point to the back chain 
> of the
> previous frame, and the variable would be found, as the offset is negative 
> (-36),
> so ("previous back chain address" - 36) is the correct variable address.
> >
> > My code is very simple:
> > =
> > #include 
> > #include 
> >
> > int main(void) {
> >int a = 2;
> >printf("a address: %p \n", (void*)&a);
> >printf("a = %d \n", a);
> >return 0;
> > }
> > =
> >
> > And I'm using the commands:
> > gcc -O0 -ggdb stest.cpp (gcc  version 5.4.1 20170304)
> > clang -O0 -ggdb stest.cpp
> >
> >
> > I think it is not related with the variable type, right?
> 
> It might be, can you show the DWARF for the 0x3b type? This was in your GCC
> variable's DWARF:
> 
> >   DW_AT_type: <0x3b>

It is a 4 byte signed integer:

<1><3b>: Abbrev Number: 3 (DW_TAG_base_type)
<3c>   DW_AT_byte_size   : 4
<3d>   DW_AT_encoding: 5(signed)
<3e>   DW_AT_name: int

> 
> There should be nothing wrong with that as long as LLDB is correctly setting 
> r31
> into the expression stack in response to the DW_OP_call_frame_cfa opcode. It
> should grab r31 - 36 and push the result onto the expression stack with
> eValueTypeLoadAddress as the type. Then we just need to read the type from
> memory. Sinc

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

2017-09-19 Thread Greg Clayton via lldb-dev

So you need to fix "DW_OP_call_frame_cfa" so it creates the same kind of value 
on the expression stack as "DW_OP_reg31" does. I am guessing that "DW_OP_reg31" 
will have a Value that whose value is "eValueTypeScalar". Verify this and 
change "DW_OP_call_frame_cfa" to match. We want the Scalar gotten by:

  Scalar value;
  if (frame->GetFrameBaseValue(value, error_ptr)) {

To be the same kind of value. Seems the expression parsing code that uses 
"DW_OP_call_frame_cfa" is doing the wrong thing by setting the value to a load 
address type.

> On Sep 19, 2017, at 10:51 AM, Leonardo Bianconi 
>  wrote:
> 
> 
> 
>> -Original Message-
>> From: Greg Clayton [mailto:clayb...@gmail.com]
>> Sent: terça-feira, 19 de setembro de 2017 12:33
>> To: Leonardo Bianconi 
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Reading eValueTypeLoadAddress with missing compiler
>> type
>> 
>> 
>>> On Sep 19, 2017, at 4:10 AM, Leonardo Bianconi
>>  wrote:
>>> 
>>> Some more details:
>>> 
>>> I'm part of the team that is working in LLDB to enable PPC64le 
>>> architecture, so
>> I'm running my test in a Power8 machine.
>>> When compiling the code with clang, it works, the issue happen when 
>>> compiling
>> with gcc, which generates a different debug information content.
>>> 
>>> Talking a bit about the power stack frame, it is organized this way:
>>> 
>>> Suppose that you have two functions a() and b() and a calls b, then the 
>>> frames
>> will be like this:
>>> 
>>> high address
>>> +-+
>>> |  ...| // frame of a
>>> |  ...|
>>> |  ...|
>>> |  ...|
>>> |  ...|
>>> |   back chain|  // r31 and r1 points here when running function a
>>> +-+
>>> |  ...| // frame of b
>>> |variable address |
>>> |  ...|
>>> |  ...|
>>> |  ...|
>>> |   back chain|  // r31 and r1 points here when running function b
>>> +-+
>>> low address
>>> 
>>> The debug information related to find the variable with clang is:
>>> <2><6ce>: Abbrev Number: 27 (DW_TAG_variable)
>>>   <6cf>   DW_AT_location: 3 byte block: 91 f0 0   (DW_OP_fbreg: 112)
>>>   <6d3>   DW_AT_name: (indirect string, offset: 0x1cf): a
>>>   <6d7>   DW_AT_decl_file   : 5
>>>   <6d8>   DW_AT_decl_line   : 6
>>>   <6d9>   DW_AT_type: <0x1bf>
>>> <2><6dd>: Abbrev Number: 0
>>> <1><6de>: Abbrev Number: 0
>>> <1><6b5>: Abbrev Number: 26 (DW_TAG_subprogram)
>>>   <6b6>   DW_AT_low_pc  : 0x1630
>>>   <6be>   DW_AT_high_pc : 0x88
>>>   <6c2>   DW_AT_frame_base  : 1 byte block: 6f(DW_OP_reg31 (r31))
>>>   <6c4>   DW_AT_name: (indirect string, offset: 0x1ca): main
>>>   <6c8>   DW_AT_decl_file   : 5
>>>   <6c9>   DW_AT_decl_line   : 5
>>>   <6ca>   DW_AT_type: <0x1bf>
>>>   <6ce>   DW_AT_external: 1
>>> 
>>> Which uses the r31 (DW_OP_reg31) and a positive offset (112) to find it, 
>>> which
>> is ok, as it does not need to read the memory using the address in the r31
>> register.
>>> 
>>> The issue happen when using the debug information generated by gcc, which
>> is:
>>> <2><9e>: Abbrev Number: 5 (DW_TAG_variable)
>>>   <9f>   DW_AT_name: a
>>>  DW_AT_decl_file   : 1
>>>  DW_AT_decl_line   : 6
>>>  DW_AT_type: <0x3b>
>>>  DW_AT_location: 2 byte block: 91 5c  (DW_OP_fbreg: -36)
>>> <1><81>: Abbrev Number: 4 (DW_TAG_subprogram)
>>>   <82>   DW_AT_external: 1
>>>   <82>   DW_AT_name: (indirect string, offset: 0xe): main
>>>   <86>   DW_AT_decl_file   : 1
>>>   <87>   DW_AT_decl_line   : 5
>>>   <88>   DW_AT_type: <0x3b>
>>>   <8c>   DW_AT_low_pc  : 0x840
>>>   <94>   DW_AT_high_pc : 0xf8
>>>   <9c>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
>>>   <9e>   DW_AT_GNU_all_tail_call_sites: 1
>>> 
>>> Here, it says to use the "DW_OP_call_frame_cfa", that is correctly executed 
>>> in
>> the LLDB, obtaining the content of r31 and setting it as "
>> lldb_private::Value::eValueTypeLoadAddress", which means the data it is 
>> looking
>> for is located in the address obtained in the r31, and it need to be read 
>> from
>> memory. If the address was correctly read, it would point to the back chain 
>> of the
>> previous frame, and the variable would be found, as the offset is negative 
>> (-36),
>> so ("previous back chain address" - 36) is the correct variable address.
>>> 
>>> My code is very simple:
>>> =
>>> #include 
>>> #include 
>>> 
>>> int main(void) {
>>>   int a = 2;
>>>   printf("a address: %p \n", (void*)&a);
>>>   printf("a = %d \n", a);
>>>   return 0;
>>> }
>>> =
>>> 
>>> And I'm using the commands:
>>> gcc -O0 -ggdb stest.cpp (gcc  version 5.4.1 20170304)
>>> clang -O0 -ggdb stest.cpp
>>> 
>>> 
>>> I think it is not related with the variable type, right?
>> 
>> It might be, can you show t

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

2017-09-19 Thread Tatyana Krasnukha via lldb-dev

Hello,

‘target modules load -lp’  fails with error “one or more section name + load 
address pair must be specified”, works only with --slide option.

Another issue is that if breakpoint is set, Process::WriteMemory  return zero 
and ObjectFile::LoadInMemory interprets it as an error without setting 
appropriate status. Thus, user sees nothing in output as if command succeeds.

Thanks,
Tatyana

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Tuesday, 19 September, 2017 6:06 PM
To: cui bixiong 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform?

Load like "target modules load" has a --load option that will load the ELF into 
memory. I think it should do what you want. Let me know how it goes.

Greg Clayton

On Sep 18, 2017, at 9:58 PM, cui bixiong 
mailto:cuibixi...@gmail.com>> wrote:

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 
mailto:clayb...@gmail.com>>:
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 
mailto: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:2f6465762f7074732f343238#b6
<   4> read packet:

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

2017-09-19 Thread Greg Clayton via lldb-dev

So the problem is bare boards have no dynamic loader. There is a 
DynamicLoaderStatic which will load files at the address that they are 
specified in the object files. When you load your ELF file using:

(lldb) file /path/to/foo.elf

What does:

(lldb) target list

show as the output? You might want to specify "none" for both the vendor and OS 
in your target triple when creating your target:

(lldb) file --arch armv7-none-none /path/to/foo.elf

This specifies there is no vendor (first "none" in the triple) and no operating 
system  (second "none" in the triple). The target's triple helps it select the 
right plug-ins to use like the dynamic load plug-in (which tells LLDB where 
sections from binaries got loaded), runtime plug-ins and much more.

So you might try:

(lldb) target modules load --load --set-pc-to-entry --slide 0 --file 
/path/to/foo.elf

Or, you can specify the addresses of all the sections using:

(lldb) target modules load --load --set-pc-to-entry --file /path/to/foo.elf 
.text 0x1000 .data 0x2000 

This allows you to completely control where each section goes and possibly skip 
other sections. It also informs LLDB that sections have been loaded at specific 
addresses.

FYI: We will have to tweak LLDB for baseboard support as it has been used bit 
by a few folks (check the "svn blame" for who added the "--load" option and 
possibly contact them) but I am sure it needs to be improved.

So try specifying "--arch -none-none" and see where that gets you. It 
should select the right dynamic loader plug-in for you. 

A bit more explanation about loading. LLDB has the notion of "file addresses" 
and "load addresses". A file address is valid for one file only, and it is the 
same as the addresses that are contained within the object file (ELF, Mach-O, 
COFF). When breakpoints are set by file + line or by name, we resolve these to 
"section .text + 100 in file foo.elf". Breakpoints can't be set until a section 
has a "load address" which will tell us where each section actually is mapped 
inside the process being debugged. For bare boards there is no dynamic linker 
that tell us '".text" was loaded at address 0x123'. If the 
DynamicLoaderStatic is selected for a target, which is done by having no OS in 
the target triple for the target, it will set the load address for the sections 
to match the "file addresses" and breakpoints will then be set. When a section 
is "loaded", a message is sent around LLDB to indicate a section was loaded, 
and all breakpoints will now be able to resolve themselves (get the "load 
address" for each "file address" for each breakpoint) and they will be set in 
the debugged process. Your extra step where you need LLDB to load your ELF file 
is now in the mix as well.

So I would recommend:
1 - create your target first:
(lldb) file --arch armv7-none-none /path/to/foo.elf
2 - attach to the baseboard
(lldb) gdb-remote 
3 - load the file in memory
(lldb) target modules load --load --set-pc-to-entry --slide 0 --file 
/path/to/foo.elf
4 - set breakpoints now
(lldb) breakpoint set ...

Usually you can set the breakpoints before your attach, but in your case you 
probably want to load the ELF file before you set breakpoints, otherwise you 
might end up setting breakpoints as soon as the "gdb-remote ..." attach happens 
since the DynamicLoaderStatic will correctly set the load addresses of all your 
sections after attaching which will cause breakpoint to resolve and attempt 
write traps to memory. Then if we load the ELF file in step #3 and when it 
writes all of the ELF sections to memory it will overwrite the breakpoint traps 
we set. So try the above flow and let us know how things go.

Greg Clayton

> On Sep 19, 2017, at 11:21 AM, Tatyana Krasnukha 
>  wrote:
> 
> Hello,
>  
> ‘target modules load -lp’  fails with error “one or more section name + load 
> address pair must be specified”, works only with --slide option.
>  
> Another issue is that if breakpoint is set, Process::WriteMemory  return zero 
> and ObjectFile::LoadInMemory interprets it as an error without setting 
> appropriate status. Thus, user sees nothing in output as if command succeeds.
>  
> Thanks,
> Tatyana
>  
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
> Clayton via lldb-dev
> Sent: Tuesday, 19 September, 2017 6:06 PM
> To: cui bixiong 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform?
>  
> Load like "target modules load" has a --load option that will load the ELF 
> into memory. I think it should do what you want. Let me know how it goes.
>  
> Greg Clayton
>  
> On Sep 18, 2017, at 9:58 PM, cui bixiong  > wrote:
>  
> 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 "targe

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

2017-09-19 Thread Tatyana Krasnukha via lldb-dev

> -Original Message-
> From: Greg Clayton [mailto:clayb...@gmail.com]
> Sent: Tuesday, 19 September, 2017 9:48 PM
> To: Tatyana Krasnukha 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform?
> 
> So the problem is bare boards have no dynamic loader. There is a
> DynamicLoaderStatic which will load files at the address that they are
> specified in the object files. When you load your ELF file using:
> 
> (lldb) file /path/to/foo.elf
> 
> What does:
> 
> (lldb) target list
> 
> show as the output? You might want to specify "none" for both the vendor
> and OS in your target triple when creating your target:
> 

It shows just what expected: * target #0: xxx.elf ( arch=arc-*-*, platform=host 
)

> (lldb) file --arch armv7-none-none /path/to/foo.elf
> 
> This specifies there is no vendor (first "none" in the triple) and no 
> operating
> system  (second "none" in the triple). The target's triple helps it select the
> right plug-ins to use like the dynamic load plug-in (which tells LLDB where
> sections from binaries got loaded), runtime plug-ins and much more.
> 
> 
> So you might try:
> 
> (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
> /path/to/foo.elf

set-pc-to-entry, not --set-pc-to-entry. May by typo in sources.

‘target modules load --load set-pc-to-entry --slide 0’ is enough, but just 
compare this text with ‘load’ in gdb… Looks like someone hates bare-metal 
developers))

> 
> Or, you can specify the addresses of all the sections using:
> 
> (lldb) target modules load --load --set-pc-to-entry --file /path/to/foo.elf 
> .text
> 0x1000 .data 0x2000 

This is a good feature, but again, how often is it needed comparing with simple 
load…

> 
> This allows you to completely control where each section goes and possibly
> skip other sections. It also informs LLDB that sections have been loaded at
> specific addresses.
> 
> FYI: We will have to tweak LLDB for baseboard support as it has been used bit
> by a few folks (check the "svn blame" for who added the "--load" option and
> possibly contact them) but I am sure it needs to be improved.
> 
> So try specifying "--arch -none-none" and see where that gets you. It
> should select the right dynamic loader plug-in for you.
> 
> A bit more explanation about loading. LLDB has the notion of "file addresses"
> and "load addresses". A file address is valid for one file only, and it is the
> same as the addresses that are contained within the object file (ELF, Mach-O,
> COFF). When breakpoints are set by file + line or by name, we resolve these
> to "section .text + 100 in file foo.elf". Breakpoints can't be set until a 
> section
> has a "load address" which will tell us where each section actually is mapped
> inside the process being debugged. For bare boards there is no dynamic
> linker that tell us '".text" was loaded at address 0x123'. If the
> DynamicLoaderStatic is selected for a target, which is done by having no OS in
> the target triple for the target, it will set the load address for the 
> sections to
> match the "file addresses" and breakpoints will then be set. When a section
> is "loaded", a message is sent around LLDB to indicate a section was loaded,
> and all breakpoints will now be able to resolve themselves (get the "load
> address" for each "file address" for each breakpoint) and they will be set in
> the debugged process. Your extra step where you need LLDB to load your
> ELF file is now in the mix as well.
> 
> So I would recommend:
> 1 - create your target first:
> (lldb) file --arch armv7-none-none /path/to/foo.elf
> 2 - attach to the baseboard
> (lldb) gdb-remote 
> 3 - load the file in memory
> (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
> /path/to/foo.elf
> 4 - set breakpoints now
> (lldb) breakpoint set ...
> 

Of course I used incorrect order of commands, I just wanted to note that 
ObjectFile::LoadInMemory should set error status when it cannot write memory.

> 
> Usually you can set the breakpoints before your attach, but in your case you
> probably want to load the ELF file before you set breakpoints, otherwise you
> might end up setting breakpoints as soon as the "gdb-remote ..." attach
> happens since the DynamicLoaderStatic will correctly set the load addresses
> of all your sections after attaching which will cause breakpoint to resolve 
> and
> attempt write traps to memory. Then if we load the ELF file in step #3 and
> when it writes all of the ELF sections to memory it will overwrite the
> breakpoint traps we set. So try the above flow and let us know how things
> go.
> 
> Greg Clayton
> 
> 
> 
> 
>   On Sep 19, 2017, at 11:21 AM, Tatyana Krasnukha
>   > wrote:
> 
>   Hello,
> 
>   ‘target modules load -lp’  fails with error “one or more section name
> + load address pair must be specified”, works only with --slide option.
> 
>   Anot

[lldb-dev] [Bug 34676] New: check-lldb target fails on Windows due to incomplete compiler path

2017-09-19 Thread via lldb-dev

https://bugs.llvm.org/show_bug.cgi?id=34676

Bug ID: 34676
   Summary: check-lldb target fails on Windows due to incomplete
compiler path
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: amcca...@google.com
CC: llvm-b...@lists.llvm.org

`ninja check-lldb` fails when it attempts this command:

```
cmd.exe /C "cd /D D:\src\llvm\build\mono\tools\lldb\test &&
C:\python_35\python_d.exe D:/src/llvm/mono/llvm-project/lldb/test/dotest.py
--no-multiprocess --arch=i686 --executable D:/src/llvm/build/mono/bin/lldb.exe
-s D:/src/llvm/build/mono/lldb-test-traces -S nm -u CXXFLAGS -u CFLAGS -C
D:\src\llvm\build\ninja_release\bin --rerun-all-issues --enable-crash-dialog"
```

The problem is that the `-C` option is specifying a directory rather than a
full path to the clang executable.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 34676] check-lldb target fails on Windows due to incomplete compiler path

2017-09-19 Thread via lldb-dev

https://bugs.llvm.org/show_bug.cgi?id=34676

Adrian McCarthy  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |amcca...@google.com

--- Comment #1 from Adrian McCarthy  ---
I'm starting with git bisect to see if I can pinpoint when this got broken.  It
looks like it may have been a while back already.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
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?

2017-09-19 Thread Greg Clayton via lldb-dev


> On Sep 19, 2017, at 1:49 PM, Tatyana Krasnukha 
>  wrote:
> 
>> -Original Message-
>> From: Greg Clayton [mailto:clayb...@gmail.com]
>> Sent: Tuesday, 19 September, 2017 9:48 PM
>> To: Tatyana Krasnukha 
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform?
>> 
>> So the problem is bare boards have no dynamic loader. There is a
>> DynamicLoaderStatic which will load files at the address that they are
>> specified in the object files. When you load your ELF file using:
>> 
>> (lldb) file /path/to/foo.elf
>> 
>> What does:
>> 
>> (lldb) target list
>> 
>> show as the output? You might want to specify "none" for both the vendor
>> and OS in your target triple when creating your target:
>> 
> 
> It shows just what expected: * target #0: xxx.elf ( arch=arc-*-*, 
> platform=host )
> 
>> (lldb) file --arch armv7-none-none /path/to/foo.elf
>> 
>> This specifies there is no vendor (first "none" in the triple) and no 
>> operating
>> system  (second "none" in the triple). The target's triple helps it select 
>> the
>> right plug-ins to use like the dynamic load plug-in (which tells LLDB where
>> sections from binaries got loaded), runtime plug-ins and much more.
>> 
>> 
>> So you might try:
>> 
>> (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
>> /path/to/foo.elf
> 
> set-pc-to-entry, not --set-pc-to-entry. May by typo in sources.
> 
> ‘target modules load --load set-pc-to-entry --slide 0’ is enough, but 
> just compare this text with ‘load’ in gdb… Looks like someone hates 
> bare-metal developers))

As I said, we haven't done a lot of bare board development in LLDB as of yet.
> 
>> 
>> Or, you can specify the addresses of all the sections using:
>> 
>> (lldb) target modules load --load --set-pc-to-entry --file /path/to/foo.elf 
>> .text
>> 0x1000 .data 0x2000 
> 
> This is a good feature, but again, how often is it needed comparing with 
> simple load…

This is mostly used when using LLDB for symbolication. On MacOSX, the crashlogs 
contains just the address of the .text segment as all other segments are not 
rigidly slid, so we often do:

(lldb) image load --file a.out __TEXT 0x100203000

So it isn't needed for baseboard, but is much more geared toward OSs running 
binaries that are dynamically loaded.

As I said before, we will have some growing pains with LLDB and bard boards, 
but lets make a solution that works for everyone. I would be happy to accept 
patches that allows us to not have to specify "--slide 0" if there is no OS in 
the target triple. We could also do patches where if a module is written to 
memory, it invalidates any breakpoints for the module that was just loaded and 
rewrites them into memory.

> 
>> 
>> This allows you to completely control where each section goes and possibly
>> skip other sections. It also informs LLDB that sections have been loaded at
>> specific addresses.
>> 
>> FYI: We will have to tweak LLDB for baseboard support as it has been used bit
>> by a few folks (check the "svn blame" for who added the "--load" option and
>> possibly contact them) but I am sure it needs to be improved.
>> 
>> So try specifying "--arch -none-none" and see where that gets you. It
>> should select the right dynamic loader plug-in for you.
>> 
>> A bit more explanation about loading. LLDB has the notion of "file addresses"
>> and "load addresses". A file address is valid for one file only, and it is 
>> the
>> same as the addresses that are contained within the object file (ELF, Mach-O,
>> COFF). When breakpoints are set by file + line or by name, we resolve these
>> to "section .text + 100 in file foo.elf". Breakpoints can't be set until a 
>> section
>> has a "load address" which will tell us where each section actually is mapped
>> inside the process being debugged. For bare boards there is no dynamic
>> linker that tell us '".text" was loaded at address 0x123'. If the
>> DynamicLoaderStatic is selected for a target, which is done by having no OS 
>> in
>> the target triple for the target, it will set the load address for the 
>> sections to
>> match the "file addresses" and breakpoints will then be set. When a section
>> is "loaded", a message is sent around LLDB to indicate a section was loaded,
>> and all breakpoints will now be able to resolve themselves (get the "load
>> address" for each "file address" for each breakpoint) and they will be set in
>> the debugged process. Your extra step where you need LLDB to load your
>> ELF file is now in the mix as well.
>> 
>> So I would recommend:
>> 1 - create your target first:
>>(lldb) file --arch armv7-none-none /path/to/foo.elf
>> 2 - attach to the baseboard
>>(lldb) gdb-remote 
>> 3 - load the file in memory
>>(lldb) target modules load --load --set-pc-to-entry --slide 0 --file
>> /path/to/foo.elf
>> 4 - set breakpoints now
>>(lldb) breakpoint set ...
>> 
> 
> Of course I used incorrect order of commands, I just wanted to

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

Re: [lldb-dev] Prologue instructions having line information

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

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

Re: [lldb-dev] Prologue instructions having line information

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

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

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

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

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

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

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

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

[lldb-dev] [Bug 34676] New: check-lldb target fails on Windows due to incomplete compiler path

[lldb-dev] [Bug 34676] check-lldb target fails on Windows due to incomplete compiler path

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

16 matches

Site Navigation

Mail list logo

Footer information