On the "Testing LLDB" tutorial page, in the description under "RUNNING
TESTS -> Running the full test suite" section, should this
> cmake -DLLDB_TEST_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
> ninja check-lldb
be
> cmake -DLLDB_TEST_USER_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
>
It looks like LLDB doesn't like ELF relocatable files for debugging
and asserts with the following message when tried
/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228:
unsigned int ObjectFileELF::RelocateSection(.): Assertion `false
&& "unexpected relocation type"' failed.
Are
On Thu, Feb 16, 2017 at 10:26 PM, Greg Clayton wrote:
>
> On Feb 16, 2017, at 3:51 AM, Ramana via lldb-dev
> wrote:
>
> It looks like LLDB doesn't like ELF relocatable files for debugging
> and asserts with the following message when tried
>
> /lldb/
Hi,
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
L
Hi,
Could someone please help me on the below?
Thanks,
Ramana
On Mon, Jun 12, 2017 at 11:58 AM, Ramana wrote:
> Hi,
>
> 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
Hi,
I am trying to remote debug ARM (linux) target from x86 (linux) host
and I am getting the following error while trying to launch a process.
The local debugging on ARM works.
error: connect remote failed (invalid host:port specification: '10.10.2.3')
error: process launch failed: invalid host:
port 9, we must find the actual port we bound to and return that.
>> Seems
>> something has gone wrong with the code that discovers the port that was
>> actually bound and is not reporting that back correctly.
>>
>>
>> Should be straight forward to do by debugging the
utable: lldb-server
>>> Triple: *-*-*
>>> Arguments:
>>> argv[0]="/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server"
>>> argv[1]="gdbserver"
>>> argv[2]="tcp://10.10.12.3:0"
>>> argv[3]="--native-regs"
tening before
>>> a connection is established. That might reproduce the issue in a more easy
>>> to debug environment.
>>>
>>> -Chris
>>>
>>>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev
>>>> wrote:
>>>>
> misbehaving.
>>>>>
>>>>> I'm unlikely to have time to investigate further until next week, but it
>>>>> should be possible to craft a unit test that verifies that
>>>>> GetLocalPortNumber() returns non-zero on a socket that is listening
>
gt;>>>>
>>>>>> Since lldb-server only supports running on a limited set of host
>>>>>> operating systems it is hard for me to diagnose the issue completely,
>>>>>> but I suspect the problem is caused by the fact that the new listen
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?
At least I did not encounter the below issue on Ubuntu 16.04 (with x86
i.e 32bit) machine with lldb v5.0.
FYI, I have built the tool chain from the RELEASE_500/final tag source.
> Somebody on stack overflow is reporting:
> https://stackoverflow.com/questions/46164427/lldb-is-not-starting-an-appl
na
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Ramana
> via lldb-dev
> Sent: Wednesday, 13 September, 2017 9:00 AM
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] lldb_private::RegisterContext vs
> lldb_private:
he 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 possib
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 defi
;>>
>>> 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
s 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 su
ke 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
>>
>> >> 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 NativeRegi
gt; >> >> 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
>> >> >> c
These sort of issues I have faced in the past and in my case the
reason was I used the incorrect host triple while building LLDB (LLVM
etc).
Example:
Assuming you are using GCC/G++ compiler to build LLVM+LLDB, I would
set the LLVM_HOST_TRIPLE to the one used in the library path and not
essentia
Hi,
It appears that the lldb-server, as of v5.0, did not implement the GDB RSPs
non-stop mode (
https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop).
Am I wrong?
If the support is actually not there, what needs to be changed to enable
the same in lldb-server?
A
29, 2018 at 9:40 PM, Frédéric Riss wrote:
> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of
ton wrote:
>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of v5.0, did not implement the GDB
> RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_
> 002dStop.html#Remote-Non_002dStop
On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton wrote:
>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of v5.0, did not implement the GDB
> RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/
018, at 9:27 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> >> On Mar 29, 2018, at 9:10 AM, Frédéric Riss wrote:
> >>
> >>
> >>
> >>> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
>
t;>
> >>
> >>> On Mar 29, 2018, at 9:27 AM, Greg Clayton wrote:
> >>>
> >>>
> >>>
> >>>> On Mar 29, 2018, at 9:10 AM, Frédéric Riss wrote:
> >>>>
> >>>>
> >>>>
> >&
c Riss wrote:
>
>
>
> On Mar 29, 2018, at 9:27 AM, Greg Clayton wrote:
>
>
>
> On Mar 29, 2018, at 9:10 AM, Frédéric Riss wrote:
>
>
>
> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On
lt;
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> >> On Mar 29, 2018, at 9:10 AM, Frédéric Riss wrote:
> >>
> >>
> >>
> >>> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote
On the subject line, the ToT lldb (see code around
CommandObjectThread.cpp:1230) sets the breakpoint on the first exact
matching line of 'line-number' or the closest line number > 'line-number'
i.e. the best match.
And along with that, starting from the above exact/best matching line
number index
On Thu, Aug 2, 2018 at 3:32 AM, Jim Ingham wrote:
>
>
> > On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > On the subject line, the ToT lldb (see code around
> CommandObjectThread.cpp:1230) sets the breakpoint o
32 matches
Mail list logo
