For our builds at QUIC, we're not interested in hitting an external server to
get code. So we'd either hit the server when needed and check in the resultant
bindings, or (preferably) use bindings from upstream.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a m
Why can’t we use VS 2015 with Python 2.7?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
Turner via lldb-d
I've been working on an old rev that we'd released on; now I'm much closer
to ToT as we move towards our next major Hexagon release.
Core dumps on the old rev would print out a listing/disassembly for each
thread in the core dump. Now it doesn't.
ToT does this, on x86 Linux:
>bin/lldb ~
nting, and
is I think orthogonal to Ted's original question.
Jim
>
> On Mon, Nov 30, 2015 at 9:32 AM, Greg Clayton via lldb-dev
> wrote:
> "thread list" should just list the threads and their stop reasons (no
> backtraces). If you want backtraces just do "thread bac
r252764 changes finishSwigPythonLLDB.py to symlink the "six" module in
site-packages. six.py is a symlink to
/tools/lldb/third_party/Python/module/six/six.py. This assumes I have
access to this build's sources when I run lldb, which I don't - our
workstations don't have access to the buildbots' fil
PM
To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] swig generation and "six" module
What about requiring that the user has done "pip install six" on their machine?
On Wed, Dec 9, 2015 at 1:40 PM Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org> &g
I'm trying to get the lldb tests running using lldb built with Hexagon
support. Some tests are running correctly, but others are failing/skipped
etc.
First, I'd like to get it to skip tests that shouldn't be run. For example,
I see output that looks like this:
Configuration: arch=x86_64
compi
-working-dir) parameter, and possibly add some support there?
On 20 January 2016 at 17:48, Ted Woodward via lldb-dev
wrote:
> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are
> failing/skipped etc.
>
>
fault
archs doesn't include x86_64
On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
I’m trying to get the lldb tests running using lldb built with Hexagon support.
Some tests are running correctly, but others are failing/skipped etc.
It looks like our bot, http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc ,
has tried to update to Python 3.5 and MSVC 2015, but it can’t find python or
VC. I’ll talk to our buildmiester about it.
Should we run this guy with 2013/py2.7 or 2015/py3.5?
--
Qualcomm Innovation Center, Inc.
f you
want you could just remove your bot. If you want to keep it, then yea getting
it on VS2015 and Python 3 would be the best idea.
On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
It looks like our bot, http://lab.llvm.org:8011/builde
//lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015]. If you
want you could just remove your bot. If you want to keep it, then yea getting
it on VS2015 and Python 3 would be the best idea.
On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org&g
d
toolchain
If I remember correctly your bot isn't actually doing anything differently than
my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015]. If you
want you could just remove your bot. If you want to keep it, then yea getting
it on VS2015 and Python 3 would be t
will soon
be up to you to chase anyone who adds 2013-breaking changes...
pl
On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
wrote:
> No, it turned red Friday night/Saturday morning.
>
>
>
> Last good build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc
I'd expect "-gdb-set solib-search-path" to call "target modules search-paths
add", and it does, but only when the -target-remote command is issued. It
also doesn't handle the multiple path case, :.
I think it should:
1) Set the search path immediately when called, if the target is
conn
I'm working on getting the tests running with Hexagon, and have a question
about identifying the target architecture.
Hexagon LLVM doesn't use a couple architectures like "x86_64" or "i386",
instead we have many architectures, like "v4", "v5", "v55", "v56", v60", so
using self.getArchitecture()
Quoted strings in target.run-args aren't handled correctly.
(lldb) settings set target.run-args "foo bar"
(lldb) settings show target.run-args
target.run-args (array of strings) =
[0]: "foo bar"
This looks correct, but the Args in the ProcessLaunchInfo passed to the
Platform doesn't ha
]
Sent: Monday, February 22, 2016 6:24 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: [lldb-dev] lldb-mi and shared library path
> On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev
> wrote:
>
> I’d expect “-gdb-set solib-search-path” to call “target modules search-paths
> add”,
Background: Hexagon clang doesn't have JIT support, so lldb for Hexagon only
uses the IR Interpreter (Codeplay wrote it for us).
Sean, r260768 broke the expression parser with functions.
Without connecting to a target, I can't get the info for main:
(lldb) e main
error: Can't run the expr
Unfortunately, that leads to another error, in the Instruction::Store case.
IRInterpreter::ResolveConstantValue() returns an error because it doesn’t like
the value id of FunctionVal. “Interpreter couldn't resolve a value during
execution”.
If I go back 1 commit from r260768 (r260767), it wo
I did some digging and found where the ID is being changed from 0x5 to 0xa in
the original code.
IRForTarget::runOnModule() calls ResolveFunctionPointers(), which gets a
Constant * from BuildFunctionPointer(). This Value has an ID of 0xa, and
runOnModule() then calls the original Function’s
I added this to ResolveConstantValue():
case Value::FunctionVal:
if (const Function *constant_func = dyn_cast(constant))
{
value = 0;
return true;
}
break;
value is an APInt &, so it won’t take nul
I think I see the problem; I’ll push up a fix.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
From: Zachary Turner [mailto:ztur...@google.com]
Sent: Thursday, March 03, 2016 11:54 AM
To:
Yes, it’s up for review. Please see http://reviews.llvm.org/D17860 .
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
From: Adrian McCarthy [mailto:amcca...@google.com]
Sent: Tuesday, Marc
n.c:26, address =
>> 0x00030018
>>
>> Note we got the address correct. Now do a:
>>
>> (lldb) image dump sections dlopen
>>
>> Check to make sure all addresses for the sections look good.
>>
>> Now do:
>>
>> (lldb) gdb-remote te
Hi Rishabh,
It looks like you’re trying to use lldb commands when running lldb-mi. lldb-mi
is the gdb-mi command layer on top of lldb, primarily used by tools like
Eclipse to talk to lldb or gdb using a similar command set. These commands are
documented here: https://sourceware.org/gdb/onlin
ote tedwood-ubuntu:5556
> (lldb) image dump sections dlopen
>
> I am guessing that the sections have been moved...
>
> Let me know what you find.
>
>> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev
>> wrote:
>>
>> I’m seeing 2 issues with “targe
Check to make sure all addresses for the sections look good.
Now do:
(lldb) gdb-remote tedwood-ubuntu:5556
(lldb) image dump sections dlopen
I am guessing that the sections have been moved...
Let me know what you find.
> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev
> wrote:
>
I'm seeing 2 issues with "target modules load":
Issue #1: load address is forgotten after a connect:
(lldb) file u:\lldb_test\dlopen
Current executable set to 'u:\lldb_test\dlopen' (hexagon).
(lldb) target modules load -f dlopen -s 0x2
(lldb) b main
Breakpoint 1: where = dlope
I run lldb on Windows and Linux, launching my gdb-server based Hexagon
simulator automatically on a process launch. On Windows I'm seeing the
(lldb) prompt before the stop message, and no prompt after. On Linux I see
the prompt after.
Windows:
Current executable set to 'u:\lldb_test\factwin' (
thread list shown at the beginning, you should
see your screen be:
"hello world
(lldb) "
If you see:
"(lldb)
hello world
(lldb) "
Then you know that the erasing feature isn't working in Editline::PrintAsync()
and it will explain why you see this issue.
Greg Clayton
>
breakpoints not
>>> working correctly
>>>
>>> Sounds like something is going wrong when resolving the address. I am
>>> guessing that your sections got unloaded when you attached to your GDB
>>> remote target. So try this:
>>>
>>> (
The assert is gone – the alias to an alias behaves as expected.
There is one issue with my testcase, “command alias r run”. That’s “help r”.
The last line is “'r' is an abbreviation for 'run -c /bin/sh --'”, but that’s
not true. ‘run’ is an abbreviation for 'process launch -c /bin/sh --', and
"process launch" calls Target::Launch, which calls
PlatformHexagon::DebugProcess, which calls Target::CreateProcess, which
calls Target::DeleteCurrentProcess, which calls SectionLoadList::Clear,
which erases the section-to-addr mappings.
"gdb-remote" calls Platform::ConnectProcess, which calls
Tar
which I *do* recommend
>> you try), maybe you can go half-way and switch to 2.7+2015 (I can show you
>> how to build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it
>> will soon be up to you to chase anyone who adds 2013-breaking changes...
>>
>> pl
>
We've got an OS that implements something they call a "user PD", which is a
lot like a PIE process. To debug it, we need to get the address of the image
and then slide the target's symbols. What's the best way to get the address
from the remote stub? Linux lldb reads an AuxVector from lldb-server,
I used to work on debug software at Freescale (NXP?), and we had a PPC core
called e6500. It had 8 IACs (Instruction Address Comparators) that could be
hooked up to the trace logic in various ways, but one really useful thing you
could do was set up an IAC to turn on or off trace on a given addr
We're porting libcxx to Hexagon. Stepping the first line in wait.pass.cpp
will put lldb in a bad state - it thinks the target has resumed, but it
never sends a step or resume packet to the remote gdbserver. Sometimes it
will step part of the line, return control, then stepping again goes to the
bad
This may be true, but telling my users "you have to install six" is a
non-starter.
--
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-b
? Aren't there search paths for the modules? If
> so, we might need to put any compatibility modules into a specific directory
> and add that to the python search paths as the last path so it would always
> pick up any system versions or installed versions first,
I'm stepping over the first line of a libcxx test (source
https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit
ion/thread.condition.condvar/wait.pass.cpp ). The first line has an inlined
function call. I expect lldb to step over the breakpoint, run to the end of
the range th
ive Project
-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com]
Sent: Friday, May 06, 2016 2:41 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context
and target.source-map setting
> On May 6, 2016, at 11:22 AM, Ted Woodwar
next_frame_sc.line_entry.file = new_file_spec;
>> }
>>
>> I've put up a patch on Phabricator with Jim as reviewer.
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Au
if
>>> (target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file,
>>> new_file_spec))
>>> next_frame_sc.line_entry.file = new_file_spec;
>>> }
>>>
>>> I
Packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py, in
test_lldbmi_gdb_set_target_async_off we have this code:
self.runCmd("-gdb-set target-async off")
.
self.runCmd("-exec-run")
unexpected = [ "\*running" ] # "\*running" is async notification
What Tyro is describing is called a "Harvard architecture" -
https://en.wikipedia.org/wiki/Harvard_architecture . It contrasts with the von
Neumann architecture used by most machines today.
Hexagon has a unified memory map, but I've worked with other DSPs (Motorola
DSP56xxx) that have a code bu
A few thoughts:
1) I think lldb-mi now takes lldb commands, so you could do the log in
your manual copy/paste. The command you want is:
log enable gdb-remote packets
Do it after the stop, before the –break-insert. You’ll get a bunch of data
after the –break-insert, then do the –exec-conti
This is what Eclipse does when setting a breakpoint at main on a Hexagon
target, before -exec-run:
TX:21-break-insert -t -f main
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-Original Me
I wanted a log with Eclipse talking to lldb-mi to see if it was doing anything
odd. It's not:
-exec-continue --thread-group i1
< 5> send packet: $c#63
-list-thread-groups i1
We have lldb-mi launch hexagon-sim automatically; it launches the same way
debugserver does, with reverse-connect.
It looks like the current implementation expects the -f to be right before the
break location. So "-break-insert main" or "-break-insert -t -f main -d" would
work, but "-break-insert -t main -f -d" would not.
It also looks as if restricting the breakpoint to the thread id (incorrectly)
only work
I don’t think we can completely get rid of the lldb coding conventions doc;
we’ll need this type of thing as long as we use swig:
* enumerations that might end up being in the lldb SB API's should all be
written like:
typedef enum EnumName
{
eEnumNameFirstValue,
We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is historically
ELFOSABI_SYSV, and used by a lot of things. So not all core files identified as
ELFOSABI_NONE are Linux.
Whe lldb loads a core file with a target binary, it will merge the 2 triples.
If it can't identify the OS from
That works fine for host debug, but not so much for embedded. On Hexagon, we
support 2 OS cases - standalone (which means no OS, or an OS that lldb
doesn't know anything about) and Linux. Both our standalone simulator and
our Linux generate core dumps using ELFOSABI_NONE. We run lldb on both x86
Li
ble file from the target
and also check the target's architecture or the main executable's architecture.
There shouldn't be a problem figuring this out right?
Greg
> On Aug 26, 2016, at 8:17 AM, Ted Woodward via lldb-dev
> wrote:
>
> That works fine for host debug,
Would the misalignment really be a problem on x86? I thought the core handled
misaligned loads and stores. Unlike, say, PPC.
Either way, I'd expect the compiler to automatically align a uint64.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora F
I recently discovered a problem with watchpoints talking to the Hexagon
simulator:
(lldb) w s e 0x1000
error: Watchpoint creation failed (addr=0x1000, size=4).
error: Target supports (0) hardware watchpoint slots.
It seems that lldb now sends a qWatchpointSupportInfo packet. But this
p
I just built lldb on Ubuntu 12 with Python 3.5.1. I needed to set python
includes, python library and python executable in cmake.
I found a problem with the tests - most ran fine, but I got errors with tests
that tried to use pexpect, like TestConvenienceVariables.py.
File
"/local/scratch/ted
r instance, the corresponding
>>>> breakpoint implementation is almost totally lacking in source doc.
>>>>
>>>> * I will need to rebase this patch on the reformatted code. That
>>>> is no big deal, but I have little experience with SVN and I will
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
Turner via lldb-dev
Sent: Tuesday, September 20, 2016 12:47 PM
> This kind of philisophical debate is probably worthy of a separate thread :)
> That being said, I think asserts are typically used in places where the
Background - I'm working on getting LLDB to run on Hexagon Linux, built with
an LLVM toolchain. We're using libc++ and MUSL. The loader is a bit
squirrelly right now, so I've built LLDB statically.
I've got full source debugging in the driver, but when I step into
SBDebugger::Create, I don't ha
TCPSocket::Connect has this line:
host_str = ::inet_ntoa (*(struct in_addr
*)*host_entry->h_addr_list);
host_entry->h_addr_list is a char**, while struct in_addr contains a
uint32_t. Casting like this (char * to uint_32t *) could cause a bus error
on systems that don't allow non-al
, October 11, 2016 1:34 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
>
>
> > On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote:
> >
> > Background – I’m working on getting
0004896432811 1 0 0 is_stmt
> > prologue_end
> >
> >
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Pro
This might affect us. Do we handle it correctly?
https://reviews.llvm.org/D16697
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
lldb-dev
That'll get us at least some testing here.
-eric
On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
I believe we are good, but it would be good to verify via testing once a
compiler becomes available.
Greg
> On Oct 19, 201
Is "image search-paths add" supposed to remove all breakpoints from the
remote server? I don't think it should be doing this.
PathMappingList::Append calls Target::ImageSearchPathsChanged, which calls
Target::SetExecutableModule, which calls Target::ClearModules, which removes
the breakpoints.
-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Wednesday, November 16, 2016 2:12 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: [lldb-dev] "image search-paths add" removes all breakpoints
> from remote server
>
>
> > On Nov 16,
Windows has no concept of a default python installation, and I can’t be sure
what version of python my users have, if any, so I need to solve 2 problems:
1) Where is python when I’m building?
2) Where is python when I’m running?
To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, a
LLDB_DEFAULT_PYTHONHOME is an internal thing; I haven’t upstreamed it – for a
while, it conflicted with Zach’s implementation, but I redid it, and everything
is happy now. If you think it would be useful, I could upstream it. It’s fairly
small, and plays nice with Zach’s Python stuff.
The pr
I've also never seen either problem. I'm not debugging Windows apps, but
Hexagon apps, running lldb and the Hexagon simulator on Win7.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
> -Ori
Hi Abid,
How are you communicating with the ARM? lldb->gdbserver->jtag probe? We've
discussed doing that kind of thing with Hexagon, but we're nowhere near
implementing it.
"process launch" on linux can download the target to the remote machine when
connected in platform mode. If you make your
packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this
decorator:
@expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238")
On Linux, I'm building with hexagon-clang, and this decorator fires, so the
test is xfailed.
On Windows, I'm building with hexagon-clang.
_version=None,
remote=None):
...
skip_for_compiler = _match_decorator_property(
compiler, self.getCompiler()) and
self.expectedCompilerVersion(compiler_version)
On Fri, Jan 6, 2017 at 10:11 AM Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org> &
The compiler redistributable is also widely available:
https://www.microsoft.com/en-us/download/details.aspx?id=48145
The python 3.5 dll would still use the runtime dll; lldb should do the same.
I’ve had crashes in the past because lldb and python used different runtimes.
--
Qua
Try "image search-paths add" as a replacement for "set solib-search-path"
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf O
Does lldb-mi support non-stop mode?
If so, is there a way to set it besides "settings set target.non-stop-mode
true"?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
Does lldb-mi support non-stop mode?
If so, is there a way to set it besides “settings set target.non-stop-mode
true”?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc.
kely to
> want them to hit breakpoints anyway... But the current help text for the
> non-stop setting should probably include some appropriate caveats.
>
> Jim
>
>
> >
> > Greg
> >
> >> On Feb 3, 2017, at 7:54 AM, Ted Woodward via lldb-dev d...@lists.l
mode is only likely to work
> >> reliably if the threads you are allowing to run never stop - hit
> >> breakpoints, crash or whatever - so worrying about missing breakpoints is
> a second order problem.
> >>
> >> Anyway, even as it i
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
Labath via lldb-dev
Sent: Friday, March 17, 2017 4:48 AM
> On 16 March 2017 at 21:43, Kamil Rytarowski wrote:
>> I imagined a possible flow of ResumeAction calls like:
>> [Generic/Native framework knows upfront the imag
On standalone Hexagon (no OS support), we use Dinkumware for the c/c++
library. LLDB isn't able to print out values of a vector:
Process 1 stopped
* thread #1: tid = 0x0001, 0x519c vector.elf`main + 76 at vector.cpp:10,
stop reason = step in
frame #0: 0x519c vector.elf`main + 76 at vec
Hi Russell,
I assume you mean for SBTarget::Launch or LaunchSimple to launch a Windows
application.
The short answer is, this already works.
SBTarget::Launch calls Target::Launch, which calls DebugProcess in the relevant
platform. For cases where we use lldb-server, the platform make
I wonder if lldb isn’t using the windows platform. In the lldb command line,
load up your target, then type “target list”. I’d like to see what plaform it
chose, and what the triple is.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Chris, Pavel,
I've got a problem launching the hexagon simulator from lldb. It's launched
the same way that debugserver/lldb-server is launched, with reverse connect
on a TCP socket. The user can modify the simulator command line (using
target.run-args), and can easily give a set of options tha
LLDBConfig.cmake has this:
if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
message("Python installation is corrupt. Python support will be disabled
for this build.")
set(LLDB_DISABLE_PYTHON
eason why the check is written as it is now.
>
> I'm not sure what would be the appropriate behavior in this case if only one
> of the pythons is available.
>
> On 19 May 2017 at 21:42, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote:
> > LLDBConfi
To expand on Jim's message, "target modules search-paths add" can be used to
help lldb find the host-side copies of shared libraries when they're not in
the same directory as on the target system.
For example, if you have libraries in /usr/lib on the target system, and have
copies on the host
lldb-mi uses the gdb/mi interface, which is defined here:
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html . The lldb-mi
implementation is slightly different in some ways, but nothing that should
affect what you want to do.
Looking at the code (in /tools/lldb-mi/MICmdCmdFile.cpp) fo
I have a simple testcase that modifies the value pointed to by an int *.
I've created a variable with -var-create, and then after the value has been
updated, check it with -var-update. -var-update returns no changes, but the
value has changed.
test.c:
#include
int main(void)
{
int vec[] = {1,
u
> e",type_changed="false",has_more="0"}]
>
> This problem exist for aggregate types too.
>
> I think I can put the fix for the first problem if it will help you.
Please let me
> know.
>
> Thanks,
> Abid
>
What we can't do is require the remote server to support the new protocol.
lldb-server isn't the only thing we talk to, and failing because we didn't get
a specific non-RSP conformant error packet would be bad.
I like Pavel's idea of enabling it via a Q packet, and after being enabled it
should
Python support on Windows is much more problematic than support on something
like MacOS or Linux. The python you use when you run lldb must be the same
python used when you build it. Bad things happen – warnings, crashes, etc –
when you use a different rev of the dll/so or the library directory
Ted Woodward via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
Python support on Windows is much more problematic than support on something
like MacOS or Linux. The python you use when you run lldb must be the same
python used when you build it. Bad things happen – warnings, crashe
The first thing I'd do is use the lldb logging mechanism. lldb-server closes
its own stdout and stderr, because nobody is interested in output from the
server, just from the target. Except when you're debugging the server, so
there is an easy way to turn on logging.
Set the following environment v
This is big time overkill, but I wasn’t sure where the problem I was tracking
down was:
“lldb all:linux all:gdb-remote all”
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
Fro
The original lldb-mi implementation was to get Eclipse talking to lldb. Since
then there have been other people working on it, and other clients, but lldb-mi
is not a full implementation of the MI protocol.
The best thing to do is give us a list of commands that are failing, in a bug
opened in
Perhaps a manual packet that tells your remote server that the next "s"
packet is a reverse step, then run the lldb command "si".
It would be simpler, from a packet log analysis standpoint, if you weren't
stopped at a breakpoint location when you did this.
--
Qualcomm Innovation Center,
What should be happening is Handle_qLaunchGDBServer calls LaunchGDBServer with
a port of UINT16_MAX, which tells it to use a port in its port list. It
shouldn't have a port list, so should return 0. LaunchGDBServer calls
StartDebugServerProcess with a port of 0 in the url. StartDebugServerProce
The lldb-server launch line looks ok; it should take the port 0 arg and get a
port from the OS.
lldb is getting the port back from lldb-server in 4.0.1, as seen here:
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543
> port
But for 5.0.0 we see it fail the debugserv
I found a hang in lldb-mi's -var-update. It checks to see if a var changed,
then it checks each of the children recursively. If a child is a pointer
back to a parent, as in this case:
struct complex_type
{
int i;
struct { long l; } inner;
struct complex_type *complex_ptr;
};
void
var_
1 - 100 of 195 matches
Mail list logo
