Re: [lldb-dev] bindings as service idea

[Ted Woodward via lldb-dev]

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 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-dev
Sent: Thursday, November 19, 2015 11:45 AM
To: Todd Fiala
Cc: LLDB
Subject: Re: [lldb-dev] bindings as service idea

 

Just to re-iterate, if we use the bindings as a service, then I envision 
checking the bindings in.  This addresses a lot of the potential pitfalls you 
point out, such as the "oops, you can't hit the network, no build for you" and 
the issue of production build flows not wanting to hit a third party server, 
etc.  

 

So if we do that, then I don't think falling back to local generation will be 
an issue (or important) in practice.  i.e. it won't matter if you can't hit the 
network.  The reason I say this is that if you can't hit the network you can't 
check in code either.  So, sure, there might be a short window where you can't 
do a local build , but that would only affect you if you were actively 
modifying a swig interface file AND you were actively without a network 
connection.  The service claims 99.95% uptime, and it's safe to say we are 
looking at significantly less than 100% usage of the server (given checked in 
bindings), so I think we're looking at once a year -- if that -- that anyone 
anywhere has an issue with being able to access the service.

 

And, as you said, the option can be provided to change the host that the 
service runs on, so someone could run one internally.

 

But do note, that if the goal here is to get the SWIG version bumped in the 
upstream, then we will probably take advantage of some of these new SWIG 
features, which may not work in earlier versions of SWIG.  So you should 
consider how useful it will be to be able to run this server internally, 
because if you can't run a new version of swig locally, then can you run it 
internally anywhere?  I don't know, I'll leave that for you to figure out.

 

Either way, it will definitely have the ability to use a different host, 
because that's the easiest way to debug theclient and server (i.e. run them on 
the same machine with 127.0.0.1)

 

On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala mailto:todd.fi...@gmail.com> > wrote:

For the benefit of continuity in conversation, here is what you had to say 
about it before:

 

> One possibility (which I mentioned to you offline, but I'll put it here for
others to see) is that we make a swig bot which is hosted in the cloud much
like our public build bots.  We provide a Python script that can be run on
your machine, which sends requests over to the swig bot to run swig and
send back the results.  Availability of the service would be governed by
the SLA of Google Compute Engine, viewable here:
https://cloud.google.com/compute/sla?hl=en
 
> If we do something like this, it would allow us to raise the SWIG version
in the upstream, and at that point I can see some benefit in checking the
bindings in.  Short of that, I still dont' see the value proposition in
checking bindings in to the repo.  [bits deleted]
 
> If it means we can get off of SWIG 1.x in the upstream, I will do the work
to make remote swig generation service and get it up and running.
 
I'd like feedback from others on this.  Is this something we want to consider 
doing?
>From my perspective, this seems reasonable to look into doing if we:
(a) have the service code available, and
(b) if we so choose, we can readily have the script hit another server (so that 
a consumer can have the entire setup on an internal network), and
(c: option 1) be able to fall back to generate with swig locally as we do now 
in the event that we can't hit the server
(c: option 2) rather than fall back to swig generation, use swig generation as 
primary (as it is now) but, if a swig is not found, then do the 
get-bindings-as-a-service flow.
This does open up multiple ways to do something, but I think we need to avoid a 
failure mode that says "Oops, you can't hit the network.  Sorry, no lldb build 
for you."
 
Reasoning:
For (a): just so we all know what we're using.
For (b): I can envision production build flows that will not want to be hitting 
a third-party server.  We shouldn't require that. 
For (c): we don't want to prevent building in scenarios that can't hit a 
network during the build.
 
-Todd

 

On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala mailto:todd.fi...@gmail.com> > wrote:

 

 

On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala mailto:todd.fi...@gmail.com> > wrote:

Hey Zachary,

 

I think the time pressure has gotten the better of me, so I want to apologize 
for getting snippy about the static bindings of late.  I am confident we will 
get to a good

[lldb-dev] FW: LLDB Windows Python Bindings

[Ted Woodward via lldb-dev]

 

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-dev
Sent: Thursday, November 19, 2015 12:01 PM
To: Aidan Dodds; LLDB
Subject: Re: [lldb-dev] LLDB Windows Python Bindings

 

+lldb-dev since this could be useful to other people.

 

I'm actively working on getting Python 3.5 support working.  If you want to go 
this route, it will make your life much easier.  But I don't have a fully 
passing test suite yet, there are still about 30 failing tests.  So consider 
Python 3.5 experimental, and at your own risk.  (Patches welcome!)

 

If you want to go with Python 2.7 then the test suite should pass fully, but 
there are 1-2 flaky timeouts that happen occasionally.  But it is a lot more 
work to set up and nobody ever gets it right because it's so complicated.

 

So, for Python 3.5:

1) You must use Visual Studio 2015.  2013 or earlier will not work.

2) Install Python 3.5 from python.org  

3) Run CMake with -DPYTHON_HOME=C:\Python35

4) That's it.  You're done.

 

You don't need to build your own Python 3.5, which it sounds like what you're 
doing.  If you're not trying to build your own Python 3.5, then check to make 
sure your PYTHONPATH is not set to anything.  Mixed environments could be a 
problem.  If that doesn't fix it, then debugging into it a little bit could 
help.  For example, try running C:\Python35\python_d.exe and then typing 
"import _ctypes".  It should work.  If you're doing a release build then try 
making sure that finish_swig is running python.exe, and if you're doing a debug 
build then try making sure that finish_swig is running python_d.exe.  

 

For Python 2.7

1) You must not be using Visual Studio 2015.  Only 2013 will work

2) Can you tell me what command line you're invoking CMake with? 

3) Can you open up build.ninja and search for this line:

 

Custom command for tools\lldb\CMakeFiles\finish_swig

 

And then paste the line under it back into this email?

 

On Thu, Nov 19, 2015 at 8:55 AM Aidan Dodds mailto:ai...@codeplay.com> > wrote:

Hi Zachary,

I am currently trying to produce a windows build of LLDB that has python
bindings.
There seems to be a lot of discussion on the mailing list regarding
python at the moment.

I couldn't see any documentation or instructions anywhere about how to
produce them.

I have tried with python2.7 and 3.5 varying degrees of success.
While I was able to produce a debug version of the 2.7 interpreter,
CMake seems to be looking for
python27_d+.lib, and I am not sure why the + has been appended.
My build using python 3.5 fails on finish_swig, with: ImportError: No
module named '_ctypes'.

It would be very much appreciated if you could point me to a reference
for building the bindings
on windows or even just give me some direction to the simplest way to
produce them.

Also out of interest what is that state of the lldb test suite on windows?

Thanks,
Aidan

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

[lldb-dev] Linux core dump doesn't show listing when loaded

[Ted Woodward via lldb-dev]

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 ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore

(lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core
"/usr2/tedwood/lldb_test/coredump/lincore"

Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.

(lldb) thread list

Process 0 stopped

* thread #1: tid = 0, 0x00401190 lincrash`main + 16 at lincrash.c:5,
name = 'lincrash', stop reason = signal SIGSEGV

(lldb)

 

I can see the listing by going up and down the stack, but I'd like to see
the listing on load. Is the no listing intended?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

[Ted Woodward via lldb-dev]

I don't think we should automatically print a backtrace after the target 
create; just the stop reason and source (or disassembly) listing, ideally only 
for the crashed thread.

Conceptually, we're loading the core file and attaching, and get a stopped 
state. The state should be completely read-only - no running, changing memory, 
registers, etc.

Process::LoadCore() shows this:

// We successfully loaded a core file, now pretend we stopped so we can
// show all of the threads in the core file and explore the crashed
// state.
SetPrivateState (eStateStopped);


Process::LoadCore() also acts like we're attaching:

DynamicLoader *dyld = GetDynamicLoader ();
if (dyld)
dyld->DidAttach();

GetJITLoaders().DidAttach();


A comment in CommandObjectTarget.cpp says we're launching the core file:

// Seems weird that we Launch a core file, but that 
is
// what we do!
error = process_sp->LoadCore();


--
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 Jim Ingham 
via lldb-dev
Sent: Wednesday, December 02, 2015 12:26 PM
To: Todd Fiala
Cc: LLDB
Subject: Re: [lldb-dev] Linux core dump doesn't show listing when loaded


> On Dec 2, 2015, at 8:35 AM, Todd Fiala via lldb-dev  
> wrote:
> 
> Does our init file mechanism have the ability to do something conditionally 
> if it's a core file?  (i.e. do we already have a way to get Ted's desired 
> behavior via an inserted call to "thread backtrace all" that somehow gets 
> triggered by the init, but only when we're talking about a core file?)
> 
> Alternatively, Ted, you could have a wrapper script of some sort (think 
> lldb-core.{sh,bat} or something) that you call that sources an lldb 
> core-file-specific init file that sets up aliases and the like to start up 
> lldb how you want, maybe?

Seems to me, the question is, is "target create --core" the same as "target 
create" or is it "target create" followed by "attach".  In the latter case, for 
"real" processes, we always print the stop state.  Since you really are 
attaching to the core process when you load a core file, the behavior of 
printing the stop state feels more right to me.  As to how that prints, 
following this logic, that should be the same as any other stop printing, 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 backtrace all".
> 
> 
> On Nov 24, 2015, at 1:09 PM, Ted Woodward via lldb-dev 
>  wrote:
> >
> > 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 ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
> > (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core 
> > "/usr2/tedwood/lldb_test/coredump/lincore"
> > Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
> > (lldb) thread list
> > Process 0 stopped
> > * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at 
> > lincrash.c:5, name = 'lincrash', stop reason = signal SIGSEGV
> > (lldb)
> >
> > I can see the listing by going up and down the stack, but I’d like to see 
> > the listing on load. Is the no listing intended?
> >
> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> > Linux Foundation Collaborative Project
> >
> > ___
> > 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
> 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

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

[lldb-dev] swig generation and "six" module

[Ted Woodward via lldb-dev]

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' filesystem, and even if
they did, the sources may change between build and run.

 

Shouldn't six.py just be copied? It's only 30k.

 

Zach, how do I do a build using static swig bindings? I don't think we're
going to change the bindings internally, so using the standard ones should
be fine.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] swig generation and "six" module

[Ted Woodward via lldb-dev]

Unfortunately, the LLDB we build needs to run on SLES 11, Ubuntu 10+ and who 
knows what else.  I don’t think I can require they install a six package. I can 
make our build do a copy instead of a link, if you want to keep it a link.

 

Are the static swig bindings checked in yet, or do we still need to run swig to 
generate them on each build?

 

--

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: Wednesday, December 09, 2015 3:47 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> > wrote:

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’ filesystem, and even if they 
did, the sources may change between build and run.

 

Shouldn’t six.py just be copied? It’s only 30k.

 

Zach, how do I do a build using static swig bindings? I don’t think we’re going 
to change the bindings internally, so using the standard ones should be fine.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> 
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] Getting lldb tests working on Hexagon

[Ted Woodward via lldb-dev]

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
compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin
/hexagon-clang

 

Or

 

Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tool
s/bin/hexagon-clang

 

Those are clearly incorrect. 

 

My dotest line is:

python dotest.py -C
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-
clang --executable /local/mnt/workspace/ted/8.0/build/bin/lldb

 

How does the -A flag affect the Configuration/Config outputs above?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Getting lldb tests working on Hexagon

[Ted Woodward via lldb-dev]

A Hexagon debug session connects to the Hexagon simulator. lldb launches 
hexagon-sim in the same way it launches lldb-server or debugserver.

When a Hexagon target is loaded, lldb automatically selects the hexagon 
platform.

So, no special settings - target create, set a breakpoint, run.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Wednesday, January 20, 2016 12:07 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: [lldb-dev] Getting lldb tests working on Hexagon

What is the sequence of lldb commands you use to innitiate a hexagon debug 
session normally? Do you need to set a custom platform (platform select XXX)? 
If so, then you need to look into --platform-name (and possibly --platform-url, 
--platform-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.
>
>
>
> 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
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Too
> ls/bin/hexagon-clang
>
>
>
> Or
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/lates
> t/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/he
> xagon-clang --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>
>
>
>
> ___
> 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] Getting lldb tests working on Hexagon

[Ted Woodward via lldb-dev]

 

Where are the default archs defined? I’m not seeing it, looking through 
testcases/dotest.py.

 

--

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: Wednesday, January 20, 2016 11:55 AM
To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] Getting lldb tests working on Hexagon

 

If it should never run with x86_64 on Hexagon, then don't bother using command 
lines, just change dotest.py so that when the target is hexagon, the default 
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. 

 

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 
compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang

 

Or

 

Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang

 

Those are clearly incorrect. 

 

My dotest line is:

python dotest.py -C 
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
 --executable /local/mnt/workspace/ted/8.0/build/bin/lldb

 

How does the –A flag affect the Configuration/Config outputs above?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto: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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

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.

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-dev
Sent: Tuesday, February 02, 2016 1:55 PM
To: Tamas Berghammer; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

 

On Tue, Feb 2, 2016 at 11:42 AM Tamas Berghammer mailto:tbergham...@google.com> > wrote:

Hi Zachary,

 

We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for 
Android Studio and we also have a buildbot what is testing this configuration 
(without sending e-mail at the moment) here: 
http://lab.llvm.org:8011/builders/lldb-windows7-android

 

We are in the discussion to decide what is our plan for going forward both in 
terms of Visual Studio version and Python version and I expect that we will 
make a decision this week. Until then please don't remove any hack we have in 
the code because of MSVC 2013 (e.g. alias template workarounds) and if adding 
new code then please try not to break MSVC 2013. I will send out an update 
about our decision hopefully at the end of this week.

Yea I mentioned already that I'm not planning on removing anything related to 
MSVC 2013, just that I'm personally not supporting it.  Which means that if 
anyone asks for help, or wants to make it work, or if it breaks accidentally, 
they're on their own :)  I don't even have MSVC 2013 installed on my machine 
anymore, so I can't fix any MSVC 2013 specific issues that arise.

 

Of course if someone else comes along and wants to help, I have no problem with 
that, but due to the difficulty of dealing with incompatibility between Python 
2 and MSVC 2015, it's just going to be up to someone else to continue making 
that work if they need it.

 

 

You mentioned that LLVM plan to bump the minimum version of MSVC to 2015. Do 
you have any link to the place where they discussed it or do you know anything 
about the schedule?

 

As far as I know the discussion hasn't started yet, but historically LLVM has 
always been pretty consistent about bumping the required MSVC version every 
12-18 months.   I know some of the Windows people on the LLVM side are already 
"unoficially" using MSVC 2015 on a regular basis, and that's usually a sign 
that people are getting an early start to see what kind of issues might be 
encountered by the general public when bumping the required version.

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

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.

 

--

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: Tuesday, February 02, 2016 2:48 PM
To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
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 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/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.

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 
<mailto:lldb-dev-boun...@lists.llvm.org> ] On Behalf Of Zachary Turner via 
lldb-dev
Sent: Tuesday, February 02, 2016 1:55 PM
To: Tamas Berghammer; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

 

On Tue, Feb 2, 2016 at 11:42 AM Tamas Berghammer mailto:tbergham...@google.com> > wrote:

Hi Zachary,

 

We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for 
Android Studio and we also have a buildbot what is testing this configuration 
(without sending e-mail at the moment) here: 
http://lab.llvm.org:8011/builders/lldb-windows7-android

 

We are in the discussion to decide what is our plan for going forward both in 
terms of Visual Studio version and Python version and I expect that we will 
make a decision this week. Until then please don't remove any hack we have in 
the code because of MSVC 2013 (e.g. alias template workarounds) and if adding 
new code then please try not to break MSVC 2013. I will send out an update 
about our decision hopefully at the end of this week.

Yea I mentioned already that I'm not planning on removing anything related to 
MSVC 2013, just that I'm personally not supporting it.  Which means that if 
anyone asks for help, or wants to make it work, or if it breaks accidentally, 
they're on their own :)  I don't even have MSVC 2013 installed on my machine 
anymore, so I can't fix any MSVC 2013 specific issues that arise.

 

Of course if someone else comes along and wants to help, I have no problem with 
that, but due to the difficulty of dealing with incompatibility between Python 
2 and MSVC 2015, it's just going to be up to someone else to continue making 
that work if they need it.

 

 

You mentioned that LLVM plan to bump the minimum version of MSVC to 2015. Do 
you have any link to the place where they discussed it or do you know anything 
about the schedule?

 

As far as I know the discussion hasn't started yet, but historically LLVM has 
always been pretty consistent about bumping the required MSVC version every 
12-18 months.   I know some of the Windows people on the LLVM side are already 
"unoficially" using MSVC 2015 on a regular basis, and that's usually a sign 
that people are getting an early start to see what kind of issues might be 
encountered by the general public when bumping the required version.

___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto: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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

Then maybe we should keep it 2013/py2.7, until llvm requires 2015.

 

--

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: Tuesday, February 02, 2016 3:43 PM
To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

It's Server 2008 R2 technically, which is the server version of Win 7 (same API 
set, same OS features, etc).  So yea, I'm pretty confident that test coverage 
is going to be 100% the same across both.  It's just a matter of if you want to 
have something that you maintain / have control over, or if you want to test 
something in a different way than what we're testing.

 

On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.

 

--

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 <mailto:ztur...@google.com> ] 
Sent: Tuesday, February 02, 2016 2:48 PM
To: Ted Woodward; LLDB


Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
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 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/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.

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 
<mailto:lldb-dev-boun...@lists.llvm.org> ] On Behalf Of Zachary Turner via 
lldb-dev
Sent: Tuesday, February 02, 2016 1:55 PM
To: Tamas Berghammer; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

 

On Tue, Feb 2, 2016 at 11:42 AM Tamas Berghammer mailto:tbergham...@google.com> > wrote:

Hi Zachary,

 

We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for 
Android Studio and we also have a buildbot what is testing this configuration 
(without sending e-mail at the moment) here: 
http://lab.llvm.org:8011/builders/lldb-windows7-android

 

We are in the discussion to decide what is our plan for going forward both in 
terms of Visual Studio version and Python version and I expect that we will 
make a decision this week. Until then please don't remove any hack we have in 
the code because of MSVC 2013 (e.g. alias template workarounds) and if adding 
new code then please try not to break MSVC 2013. I will send out an update 
about our decision hopefully at the end of this week.

Yea I mentioned already that I'm not planning on removing anything related to 
MSVC 2013, just that I'm personally not supporting it.  Which means that if 
anyone asks for help, or wants to make it work, or if it breaks accidentally, 
they're on their own :)  I don't even have MSVC 2013 installed on my machine 
anymore, so I can't fix any MSVC 2013 specific issues that arise.

 

Of course if someone else comes along and wants to help, I have no problem with 
that, but due to the difficulty of dealing with incompatibility between Python 
2 and MSVC 2015, it's just going to be up to someone else to continue making 
that work if they need it.

 

 

You mentioned that LLVM plan to bump the minimum version of MSVC to 2015. Do 
you have any link to the place where they discussed it or do you know anything 
about the schedule?

 

As far as I know the discussion hasn't started yet, but historically LLVM has 
always been pretty consistent about bumping the required MSVC version every 
12-18 months.   I know some of the Windows people on the LLVM side are already 
"unoficially" using MSVC 2015 on a regular basis, and that's usually a sign 
that people are getting an early start to see what kind of issues might be 
encountered by the general public when bumping the required version.

___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto: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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

No, it turned red Friday night/Saturday morning.

 

Last good build:

http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167

 

First bad build:

http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168

 

It went red because of the change to VS2015/Python 3.5.

 

--

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: Tuesday, February 02, 2016 5:28 PM
To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

BTW, I expect that your buildbot has been experiencing the problems with the 
x86 / x64 toolchain for quite some time, because it's not really relevant to 
how much memory your machine has, but just that it was using an x86 toolchain 
at all.  Has it been red for a long time?

 

On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner mailto:ztur...@google.com> > wrote:

You may have to make some changes to the zorg scripts to keep that working.  I 
didn't realize there were any other bots building LLDB, so I made some changes 
that will default everything to VS2015 and Py3.  

 

BTW, is your builder doing a debug build or a release build?  When doing a 
debug build clang now requires more memory than can fit in a 4GB address space 
to link, so using an x86 toolchain won't work anymore.  I forced a change to 
use the amd64_x86 toolchain, but this won't work unless the version of python 
used by buildbot is a 64-bit Python distro (because Python.exe is what 
ultimately calls vcvarsall and cmake and it inherits the environment of the 
parent).

 

So I think you will need to do all this as well.

 

On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

Then maybe we should keep it 2013/py2.7, until llvm requires 2015.

 

--

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 <mailto:ztur...@google.com> ] 
Sent: Tuesday, February 02, 2016 3:43 PM


To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

It's Server 2008 R2 technically, which is the server version of Win 7 (same API 
set, same OS features, etc).  So yea, I'm pretty confident that test coverage 
is going to be 100% the same across both.  It's just a matter of if you want to 
have something that you maintain / have control over, or if you want to test 
something in a different way than what we're testing.

 

On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.

 

--

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 <mailto:ztur...@google.com> ] 
Sent: Tuesday, February 02, 2016 2:48 PM
To: Ted Woodward; LLDB


Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
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 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/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.

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 
<mailto:lldb-dev-boun...@lists.llvm.org> ] On Behalf Of Zachary Turner via 
lldb-dev
Sent: Tuesday, February 02, 2016 1:55 PM
To: Tamas Berghammer; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

 

On Tue, Feb 2, 2016 at 11:42 AM Tamas Berghammer mailto:tbergham...@google.com> > wrote:

Hi Zachary,

 

We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for 
Android Studio and we also have a buildbot what is testing this configuration 
(without sending e-mail at the moment) here: 
http://lab.llvm.org:8011/builders/lldb-windows7-android

 

We are in the discussion to decide what is our plan for going forward both in 
terms of Visual Studio version and Python version and I expect that we will 
make a decision this

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
that.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Thursday, February 04, 2016 10:01 AM
To: Ted Woodward
Cc: Zachary Turner; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

Hi all.

we (android lldb team) are starting to transition to VS2015 as well.
For now, the plan is to stick to python 2.7, but if we encounter problems 
there, the backup plan is to go to python 3 as well. Until then (I estimate 
that will take 1--2 weeks) our buildbot 
<http://lab.llvm.org:8011/builders/lldb-windows7-android> will continue 
building 2.7+2013 and we will be making sure it works, so please don't check in 
any VS2013 incompatible code (yet).

Ted: If you can't switch to the 3+2015 combination (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


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/builds/15167
>
>
>
> First bad build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>
>
>
> It went red because of the change to VS2015/Python 3.5.
>
>
>
> --
>
> 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: Tuesday, February 02, 2016 5:28 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an 
> unsupported toolchain
>
>
>
> BTW, I expect that your buildbot has been experiencing the problems 
> with the
> x86 / x64 toolchain for quite some time, because it's not really 
> relevant to how much memory your machine has, but just that it was 
> using an x86 toolchain at all.  Has it been red for a long time?
>
>
>
> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:
>
> You may have to make some changes to the zorg scripts to keep that working.
> I didn't realize there were any other bots building LLDB, so I made 
> some changes that will default everything to VS2015 and Py3.
>
>
>
> BTW, is your builder doing a debug build or a release build?  When 
> doing a debug build clang now requires more memory than can fit in a 
> 4GB address space to link, so using an x86 toolchain won't work 
> anymore.  I forced a change to use the amd64_x86 toolchain, but this 
> won't work unless the version of python used by buildbot is a 64-bit 
> Python distro (because Python.exe is what ultimately calls vcvarsall 
> and cmake and it inherits the environment of the parent).
>
>
>
> So I think you will need to do all this as well.
>
>
>
> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward 
> 
> wrote:
>
> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>
>
>
> --
>
> 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: Tuesday, February 02, 2016 3:43 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an 
> unsupported toolchain
>
>
>
> It's Server 2008 R2 technically, which is the server version of Win 7 
> (same API set, same OS features, etc).  So yea, I'm pretty confident 
> that test coverage is going to be 100% the same across both.  It's 
> just a matter of if you want to have something that you maintain / 
> have control over, or if you want to test something in a different way than 
> what we're testing.
>
>
>
> On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward 
> 
> wrote:
>
> Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>
>
>
> --
>
> 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: Tuesday, February 02, 2016 2:48 PM
> To: Ted Woodward; LLDB
>
>
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an 
> 

[lldb-dev] lldb-mi and shared library path

[Ted Woodward via lldb-dev]

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
connected

2)  Set the search path on run/attach

3)  Handle multiple paths

 

Any thoughts on this?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

[lldb-dev] Prefered way to identify target device in tests?

[Ted Woodward via lldb-dev]

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() can be problematic. I've got a list of Hexagon
architectures in a global supported_hexagon_versions in lldbtest.py. When I
need to check for Hexagon, should I do something like "self.getArchitecture
in supported_hexagon_versions", or something like this:

 

self.runCmd("target list")

if "arch=hexagon-*-*," in self.res.GetOutput():

 

?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

[lldb-dev] problem with quoted strings in setting target.run-args

[Ted Woodward via lldb-dev]

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 have m_args_quote_char set, so if the Args is later pulled
out with GetQuotedCommandString() it won't get "foo bar", but will instead
get foo and bar unquoted. This is masked when talking to debugserver or
lldb_server because run-args are sent to the server using an RSP packet, but
on systems like Windows or the Hexagon Simulator, where run-args are on the
command line, you get 2 args, foo and bar, instead of 1 arg "foo bar".

 

The first problem is in OptionValueArray::SetArgs(), in the
eVarSetOperationAppend case. It calls Args::GetArgumentAtIndex(), which
doesn't return a quoted argument. I added a function
GetQuotedArgumentAtIndex() and called that, which revealed the second
problem. The string is passed into
OptionValue::CreateValueFromCStringForTypeMask(), which calls
OptionValueString::SetValueFromString(). In that function it explicitly
strips quotes. Changing it to not strip quotes leads to the third problem -
when TargetProperties::RunArgsValueChangedCallback() pulls the data from the
OptionValueArray to make a new Args, it calls OptionValueArray::GetArgs(),
which doesn't handle quoting like the Args ctor does.

 

I think changing the OptionValue classes to handle quoting could lead to
problems with other use cases. So that leaves me with the option of going
through the Args before launch and adding quotes around anything with
spaces, which seems hackish. Any thoughts on how to solve this issue?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] lldb-mi and shared library path

[Ted Woodward via lldb-dev]

The Hexagon SDK taking to hardware is very bare bones. The OS is sitting on the 
phone and is loaded to the Hexagon by Android. The debugger opens the OS elf 
file, the user tells it where the shared libraries are, and lldb does the usual 
stop-at-the-rendezvous function negotiation to get info when shared libraries 
are loaded. Each example application is its own shared library, and each is 
built in a different directory. I don't think I can have the Platform do the 
hard work, because the shared libraries could be anywhere.

It works fine when we run lldb; it doesn't when our Eclipse guy runs lldb-mi. 
I'm having fun looking at lots of logs!

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
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”, 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 
> connected
> 2)  Set the search path on run/attach
> 3)  Handle multiple paths
>  
> Any thoughts on this?
>  

Here are some thoughts that say kind of how we are doing things, and after 
reading this it might adjust your request:

In LLDB the approach we have taken is that when you are going to remotely debug 
something, your Platform is responsible for finding any remote file paths might 
not match the local file paths. 

For Apple with iOS, we have one or more root directories available for us to 
grab system files from (everything from /usr/lib/* /System/Library/Frameworks, 
etc). Only the executables you just built tend to exist outside of the system 
roots, so as long as your provide those to LLDB prior to running ("target 
create /path/to/locally/built/cross/executable"), we will be able to match up 
the binaries using their UUID even if the remote path is 
"/users/admin/executable". There are also ways to say "I built 
/path/to/locally/built/cross/executable and 
/path/to/locally/built/cross/libfoo.so and 
/path/to/locally/built/cross/libbar.so", now attach to a remote binary to debug 
these things. The extra .so files can be added to your target with "target 
module add /path/to/locally/built/cross/libfoo.so" and "target module add 
/path/to/locally/built/cross/libbar.so" and then we will be able to find these 
files when they are needed.

So the main questions becomes: if you modify your platform to do the right 
thing, do you need any of the changes you are requesting ("-gdb-set 
solib-search-path" or "target modules search-paths add")?

This is how things were done back with GDB, but in LLDB we are trying to make 
our Platform subclasses do a lot of this hard work for us. Your Platform could 
check with a build server and download and cache any binaries it needed. It 
could look through a set of directories or other commonly used areas for these 
files, it really depends on how your SDK/PDK is setup and how your builds tend 
to happen. If you have an IDE that is creating binaries, it typically knows 
about all of the build products you might be trying to debug, and it can often 
supply the build products to LLDB in case it needs them.

Let me know.

Greg Clayton



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

[lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Ted Woodward via lldb-dev]

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 expression locally: Interpreter doesn't handle one of
the expression's operands

 

Connected to a target, I can't run a function:

(lldb) e factorial(5)

error: Can't run the expression locally: Interpreter doesn't handle one of
the expression's operands

 

 

I've traced the failure to the call to CanResolveConstant() in
IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the
working case, the Value ID is 0xa - Value::ConstantExprVal. In the failing
case, it is 0x5. Since it's defined in a .def file, I can't be sure, but my
guess is its Value::FunctionVal.

 

 

Where is the Value ID set?

 

 

 

Some info from the expr log:

 

; Function Attrs: nounwind

define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {

entry:

  %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4

  store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4

  %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  %guard.uninitialized = icmp eq i8 %0, 0

  br i1 %guard.uninitialized, label %init.check, label %init.end

 

init.check:   ; preds = %entry

  %call = call i32 @factorial(i32 5)

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align
4

  store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  br label %init.end

 

init.end: ; preds = %init.check,
%entry

  ret void

}

 

 

Unsupported constant: declare i32 @factorial(i32) #1

 

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Ted Woodward via lldb-dev]

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 works. The value id is 0xa, 
ConstantIntVal. So something in r260768 is either setting the value id to 0x5, 
or keeping the value id from being set to 0xa.

 

Ted

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: scalla...@apple.com [mailto:scalla...@apple.com] 
Sent: Tuesday, February 23, 2016 5:41 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
expression parser with function on Hexagon

 

Ted,

 

I’m not sure who inside Clang actually sets the value ID – it’s the code 
generator’s job to make IR, we don’t construct it.

I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
returning true.

 

Sean

 

On Feb 23, 2016, at 3:28 PM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

 

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 expression locally: Interpreter doesn't handle one of the 
expression's operands

 

Connected to a target, I can’t run a function:

(lldb) e factorial(5)

error: Can't run the expression locally: Interpreter doesn't handle one of the 
expression's operands

 

 

I’ve traced the failure to the call to CanResolveConstant() in 
IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
guess is its Value::FunctionVal.

 

 

Where is the Value ID set?

 

 

 

Some info from the expr log:

 

; Function Attrs: nounwind

define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {

entry:

  %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4

  store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4

  %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  %guard.uninitialized = icmp eq i8 %0, 0

  br i1 %guard.uninitialized, label %init.check, label %init.end

 

init.check:   ; preds = %entry

  %call = call i32 @factorial(i32 5)

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4

  store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  br label %init.end

 

init.end: ; preds = %init.check, %entry

  ret void

}

 

 

Unsupported constant: declare i32 @factorial(i32) #1

 

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

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

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Ted Woodward via lldb-dev]

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 replaceAllUsesWith(), passing 
in the new Value, changing ID from 0x5 to 0xa.

 

If I comment out the call to ResolveFunctionPointer() in the original code, I 
get the same error as the current code: “error: Can't run the expression 
locally: Interpreter doesn't handle one of the expression's operands”

 

So I went to r260768 and added back in the call to ResolveFunctionPointer(), as 
well as functions that it depended on:

ClangExpressionDeclMap::FindCodeSymbolInContext()

ClangExpressionDeclMap::FindBestAlternateMangledName()

ClangExpressionDeclMap::GetFunctionAddress()

IRForTarget::GetFunctionAddress()

IRForTarget::BuildFunctionPointer()

I commented out the call to RegisterFunctionMetadata() since it didn’t seem to 
matter.

 

After those changes, I was able to print out main’s info and call functions 
with the expression parser.

 

Is there anything in these functions that I can get rid of, or is handled by 
newer code?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: scalla...@apple.com [mailto:scalla...@apple.com] 
Sent: Tuesday, February 23, 2016 6:38 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
expression parser with function on Hexagon

 

At that point, I’d set a watchpoint and see what is setting it. I would expect 
that

 

  %call = call i32 @factorial(i32 5)

would put a normal value in call, which would then be the value stored by the 
store instruction

 

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4

 

The store instruction should not have an operand of function type… right?

 

Sean

 

On Feb 23, 2016, at 4:21 PM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

 

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 works. The value id is 0xa, 
ConstantIntVal. So something in r260768 is either setting the value id to 0x5, 
or keeping the value id from being set to 0xa.

 

Ted

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: scalla...@apple.com   
[mailto:scalla...@apple.com] 
Sent: Tuesday, February 23, 2016 5:41 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
expression parser with function on Hexagon

 

Ted,

 

I’m not sure who inside Clang actually sets the value ID – it’s the code 
generator’s job to make IR, we don’t construct it.

I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
returning true.

 

Sean

 

On Feb 23, 2016, at 3:28 PM, Ted Woodward < 
 ted.woodw...@codeaurora.org> wrote:

 

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 expression locally: Interpreter doesn't handle one of the 
expression's operands

 

Connected to a target, I can’t run a function:

(lldb) e factorial(5)

error: Can't run the expression locally: Interpreter doesn't handle one of the 
expression's operands

 

 

I’ve traced the failure to the call to CanResolveConstant() in 
IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
guess is its Value::FunctionVal.

 

 

Where is the Value ID set?

 

 

 

Some info from the expr log:

 

; Function Attrs: nounwind

define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {

entry:

  %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4

  store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4

  %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  %guard.uninitialized = icmp eq i8 %0, 0

  br i1 %guard.uninitialized, label %init.check, label %init.end

 

init.check:   ; preds = %entry

  %call = call i32 @factorial(i32 5)

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4

  store i8 1, i8* @"_ZGVZ12$__lldb_expr

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Ted Woodward via lldb-dev]

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 nullptr.

 

“p main” returned the correct signature, but an address of 0.

“p factorial(5)” alternates between returning the parameter (5, in this case) 
and an error, with the program restarting when it gets the error. _start on 
Hexagon is 0, so my guess is lldb thought &factorial() was 0, so it set the pc 
to there and continued. The error is “error: Supposed to interpret, but failed: 
ThreadPlanCallFunctionUsingABI failed”. By half the time

 

Something interesting – constant_func->getName().str().c_str() gives “”. I’m 
pretty sure I want to return the address of the function, but I’m not sure how 
to get it.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: scalla...@apple.com [mailto:scalla...@apple.com] 
Sent: Wednesday, February 24, 2016 5:10 PM
To: Ted Woodward
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
expression parser with function on Hexagon

 

Yeah, I think we’ll have to return true in CanResolveConstant() for 
FunctionVal, like you did as an experiment earlier.

 

Sean

 

On Feb 24, 2016, at 3:08 PM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

 

It never gets to IRInterpreter::Interpret(); it errors out in 
IRInterpreter::CanInterpret(), in the call to CanResolveConstant() at line 656, 
so it never calls getCalledValue() or EvaluateValue().

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: scalla...@apple.com   
[mailto:scalla...@apple.com] 
Sent: Wednesday, February 24, 2016 4:36 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
expression parser with function on Hexagon

 

I think I understand what’s going on.  The IR interpreter does this 
[IRInterpreter.cpp:1573]:

–

// Find the address of the callee function

lldb_private::Scalar I;

const llvm::Value *val = call_inst->getCalledValue();

 

if (!frame.EvaluateValue(I, val, module))

{

error.SetErrorToGenericError();

error.SetErrorString("unable to get address of function");

return false;

}

–

It assumes that getCalledValue returns something we can evaluate – which used 
to be a function pointer so everything was fine.

We have to modify EvaluateValue to, when it encounters a FunctionVal, look up 
the corresponding symbol (using IRExecutionUnit::FindSymbol(), ideally) and 
return a Scalar containing the function pointer.

As a first step, I’d suggest trying to make EvaluateValue return true but just 
put nullptr into the Scalar when it gets a FunctionVal – does that result (as 
I’d expect) in a bad function call, or do we still get some kind of “doesn’t 
handle” error?

 

Sean

 

On Feb 24, 2016, at 2:17 PM, Ted Woodward < 
 ted.woodw...@codeaurora.org> wrote:

 

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 replaceAllUsesWith(), passing 
in the new Value, changing ID from 0x5 to 0xa.

 

If I comment out the call to ResolveFunctionPointer() in the original code, I 
get the same error as the current code: “error: Can't run the expression 
locally: Interpreter doesn't handle one of the expression's operands”

 

So I went to r260768 and added back in the call to ResolveFunctionPointer(), as 
well as functions that it depended on:

ClangExpressionDeclMap::FindCodeSymbolInContext()

ClangExpressionDeclMap::FindBestAlternateMangledName()

ClangExpressionDeclMap::GetFunctionAddress()

IRForTarget::GetFunctionAddress()

IRForTarget::BuildFunctionPointer()

I commented out the call to RegisterFunctionMetadata() since it didn’t seem to 
matter.

 

After those changes, I was able to print out main’s info and call functions 
with the expression parser.

 

Is there anything in these functions that I can get rid of, or is handled by 
newer code?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From:   scalla...@apple.com [ 
 mailto:scalla...@apple.com] 
Sent: Tuesday, February 23, 2016 6:

Re: [lldb-dev] FYI: a python crash running tests

[Ted Woodward via lldb-dev]

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: Adrian McCarthy; LLDB; Ted Woodward
Subject: Re: FYI: a python crash running tests

 

Hi Ted, any chance this is your recent change? I know you had some changes in 
this file recently

On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy mailto:amcca...@google.com> > wrote:

Running ninja check-lldb now has one crash in a Python process, due to 
deferencing a null pointer in IRExecutionUnit.cpp:  candidate_sc.symbol is 
null, which leads to a call with a null this pointer.

 

However, the Test Result Summary shows no problems:  0 failures, errors, 
exceptional exits, and timeouts.

 

I would try to debug it, but I'm about to head out.

 

Adrian.

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

Re: [lldb-dev] FYI: a python crash running tests

[Ted Woodward via lldb-dev]

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, March 08, 2016 11:34 AM
To: Ted Woodward
Cc: Zachary Turner; LLDB
Subject: Re: FYI: a python crash running tests

 

Did you ever push a fix?  I'm still seeing this problem, even after a fresh 
sync.

 

I'm happy to take a look at it today if you don't already have a fix.

 

On Thu, Mar 3, 2016 at 10:18 AM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

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: Adrian McCarthy; LLDB; Ted Woodward
Subject: Re: FYI: a python crash running tests

 

Hi Ted, any chance this is your recent change? I know you had some changes in 
this file recently

On Wed, Mar 2, 2016 at 4:46 PM Adrian McCarthy mailto:amcca...@google.com> > wrote:

Running ninja check-lldb now has one crash in a Python process, due to 
deferencing a null pointer in IRExecutionUnit.cpp:  candidate_sc.symbol is 
null, which leads to a call with a null this pointer.

 

However, the Test Result Summary shows no problems:  0 failures, errors, 
exceptional exits, and timeouts.

 

I would try to debug it, but I'm about to head out.

 

Adrian.

 

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

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

I found why the load addresses are getting dropped. When I do "target modules 
load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new load 
address for each section. Then when I attach, 
DynamicLoaderHexagonDYLD::DidAttach() calls 
DynamicLoaderHexagonDYLD::UpdateLoadedSections(), which calls 
Target::SetSectionLoadAddress() for each section, resetting the load address to 
the address in the relevant file.

If I remove the call to Target::SetSectionLoadAddress(), I can't hit 
breakpoints. So I need this, but I think I should only do this if the section 
isn't already loaded.


How do I tell if a section is already loaded?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, March 18, 2016 4:32 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
correctly

SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp

> On Mar 18, 2016, at 1:54 PM, Ted Woodward  wrote:
> 
> I don't see anything in the packet log that would cause the change. Most of 
> the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) 
> return an empty reply.
> 
> Where should I set a breakpoint to see the load addresses moving?
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Friday, March 18, 2016 3:12 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
> working correctly
> 
> So you will need to find out who is sliding the shared library incorrectly. 
> It might be a packet that is received through the GDB remote protocol, so 
> there might be a bug in your GDB server.
> 
> Greg
> 
>> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
>> wrote:
>> 
>> Your guess is right - the sections moved. Before attaching:
>> 
>> 0x0008 code [0x0003-0x00068d5c)  
>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>> 
>> After attaching:
>> 
>> 0x0008 code [0x0001-0x00048d5c)  
>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>> Forum, a Linux Foundation Collaborative Project
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Thursday, March 17, 2016 12:44 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] "target modules load" and 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:
>> 
>> (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 = dlopen`main + 24 at dlopen.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 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 = dlopen`main + 24 at dlopen.c:26, address =
>>> 0x00030018
>>> (lldb) gdb-remote tedwood-ubuntu:5556
>>> 
>>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>>> 0x10018 <  14> send packet: $Z0,10018,4#10
>>> <   4> re

Re: [lldb-dev] Help needed regarding LLDB/MI

[Ted Woodward via lldb-dev]

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/onlinedocs/gdb/Remote-Protocol.html 
.

 

If you’re interested in running the lldb command line debugger, don’t start MI, 
but just lldb, with “lldb”.

 

Ted

 

--

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 RISHABH 
GUPTA via lldb-dev
Sent: Friday, March 11, 2016 11:30 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Help needed regarding LLDB/MI

 

Hello all,

I have started using LLDB/MI but there are some commands that are not working 
.I start the MI in terminal as "lldb-mi-3.6 --interpreter" and then launch the 
application that  I want to debug but commands like "n" ,"list","continue" 
,"step" are not working.There is this error message that gets displayed on 
giving these commands

"^error,msg="Driver. Received command 'command_name'. It was not handled. 
Command 'continue' not in Command Factory"

I tried looking for  the substitutes of these commands here 
https://github.com/llvm-mirror/lldb/tree/7535162178eada833e72a5525fc26dcc04e7331e/tools/lldb-mi
  but could not find any.

Could anyone please help me out with this?



Thank you :)

Rishabh

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

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

I don't see anything in the packet log that would cause the change. Most of the 
interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) return an 
empty reply.

Where should I set a breakpoint to see the load addresses moving?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, March 18, 2016 3:12 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
correctly

So you will need to find out who is sliding the shared library incorrectly. It 
might be a packet that is received through the GDB remote protocol, so there 
might be a bug in your GDB server.

Greg

> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
> wrote:
> 
> Your guess is right - the sections moved. Before attaching:
> 
>  0x0008 code [0x0003-0x00068d5c)  
> 0x00011000 0x00038d5c 0x0006 dlopen..text
> 
> After attaching:
> 
>  0x0008 code [0x0001-0x00048d5c)  
> 0x00011000 0x00038d5c 0x0006 dlopen..text
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Thursday, March 17, 2016 12:44 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and 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:
> 
> (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 = dlopen`main + 24 at dlopen.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 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 = dlopen`main + 24 at dlopen.c:26, address =
>> 0x00030018
>> (lldb) gdb-remote tedwood-ubuntu:5556
>> 
>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>> 0x10018 <  14> send packet: $Z0,10018,4#10
>> <   4> read packet: $#00
>> Software breakpoints are unsupported
>> <  14> send packet: $Z1,10018,4#11
>> <   6> read packet: $OK#9a
>> 
>> (lldb) br l
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>> resolved, hit count = 0
>> 
>> 
>> 
>> 
>> Issue #2: breakpoints on the remote server aren’t updated with a new load 
>> address, even though they’re updated in the breakpoint list:
>> 
>> (lldb) br l
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>> resolved, hit count = 0
>> 
>> (lldb) target modules load -f dlopen -s 0x2
>> (lldb) br l
>> <   7> send packet: $p29#db
>> <  12> read packet: $0010#81
>> <   7> send packet: $p1d#05
>> <  12> read packet: $#80
>> Current breakpoints:
>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
>> resolved, hit count = 0
>> 
>> (lldb) c
>> Process 1 stopped
>> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1,
>> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
>>frame #0: 0x00030018 dlopen`main(argc=1, argv=0x000

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

Your guess is right - the sections moved. Before attaching:

  0x0008 code [0x0003-0x00068d5c)  
0x00011000 0x00038d5c 0x0006 dlopen..text

After attaching:

  0x0008 code [0x0001-0x00048d5c)  
0x00011000 0x00038d5c 0x0006 dlopen..text

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Thursday, March 17, 2016 12:44 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and 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:

(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 = dlopen`main + 24 at dlopen.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 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 = dlopen`main + 24 at dlopen.c:26, address = 
> 0x00030018
> (lldb) gdb-remote tedwood-ubuntu:5556
>  
> But it’s set the breakpoint at 0x10018 instead of 0x30018:
> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address = 
> 0x10018 <  14> send packet: $Z0,10018,4#10
> <   4> read packet: $#00
> Software breakpoints are unsupported
> <  14> send packet: $Z1,10018,4#11
> <   6> read packet: $OK#9a
>  
> (lldb) br l
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
> resolved, hit count = 0
>  
>  
>  
>  
> Issue #2: breakpoints on the remote server aren’t updated with a new load 
> address, even though they’re updated in the breakpoint list:
>  
> (lldb) br l
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
> resolved, hit count = 0
>  
> (lldb) target modules load -f dlopen -s 0x2
> (lldb) br l
> <   7> send packet: $p29#db
> <  12> read packet: $0010#81
> <   7> send packet: $p1d#05
> <  12> read packet: $#80
> Current breakpoints:
> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>   1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
> resolved, hit count = 0
>  
> (lldb) c
> Process 1 stopped
> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1, 
> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
> frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at 
> dlopen.c:26
>  
> (lldb) re r pc
>   pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>  
> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z 
> packet to add one at 0x30018.
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>  
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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

[lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

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 = dlopen`main + 24 at dlopen.c:26, address = 0x00030018

(lldb) gdb-remote tedwood-ubuntu:5556

 

But it's set the breakpoint at 0x10018 instead of 0x30018:

ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address = 0x10018

<  14> send packet: $Z0,10018,4#10

<   4> read packet: $#00

Software breakpoints are unsupported

<  14> send packet: $Z1,10018,4#11

<   6> read packet: $OK#9a

 

(lldb) br l

Current breakpoints:

1: name = 'main', locations = 1, resolved = 1, hit count = 0

  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018,
resolved, hit count = 0

 

 

 

 

Issue #2: breakpoints on the remote server aren't updated with a new load
address, even though they're updated in the breakpoint list:

 

(lldb) br l

Current breakpoints:

1: name = 'main', locations = 1, resolved = 1, hit count = 0

  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018,
resolved,

hit count = 0

 

(lldb) target modules load -f dlopen -s 0x2

(lldb) br l

<   7> send packet: $p29#db

<  12> read packet: $0010#81

<   7> send packet: $p1d#05

<  12> read packet: $#80

Current breakpoints:

1: name = 'main', locations = 1, resolved = 1, hit count = 0

  1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018,
resolved,

hit count = 0

 

(lldb) c

Process 1 stopped

* thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1, argv=0x00052348) +
24

at dlopen.c:26, stop reason = breakpoint 1.1

frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at
dlopen.c:26

 

(lldb) re r pc

  pc = 0x00010018  dlopen`main + 24 at dlopen.c:26

 

Note that lldb says it's stopped at 0x30018, but it's really stopped at
0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z
packet to add one at 0x30018.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

[lldb-dev] Windows lldb prompt issue

[Ted Woodward via lldb-dev]

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' (hexagon).

(lldb) b main

Breakpoint 1: where = factwin`main + 28 at factorial.c:32, address =
0x5130

(lldb) r

Process 1 launched: 'u:\lldb_test\factwin' (hexagon)

(lldb) Process 1 stopped

* thread #1: tid = 0x0001, 0x5130 factwin`main(argc=1, argv=0xe110)
+ 28 at factorial.c:32, stop reason = breakpoint 1.1

frame #0: 0x5130 factwin`main(argc=1, argv=0xe110) + 28 at
factorial.c:32

   29 }

   30   */

   31

-> 32 base = 10;

   33

   34 printf("Factorial of %d is %d\n", base, factorial(base));

   35 return 0;

 

 

Linux:

Current executable set to '/usr2/tedwood/lldb_test/factorial' (hexagon).

(lldb) b main

Breakpoint 1: where = factorial`main + 28 at factorial.c:32, address =
0x4130

(lldb) r

Process 1 launched: '/usr2/tedwood/lldb_test/factorial' (hexagon)

Process 1 stopped

* thread #1: tid = 0x0001, 0x4130 factorial`main(argc=1,
argv=0xb100) + 28 at factorial.c:32, stop reason = breakpoint 1.1

frame #0: 0x4130 factorial`main(argc=1, argv=0xb100) + 28 at
factorial.c:32

   29 }

   30   */

   31  

-> 32 base = 10;

   33  

   34 printf("Factorial of %d is %d\n", base, factorial(base));

   35 return 0;

(lldb)  

 

 

 

Any idea why the prompt is coming out before the stop message?

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Windows lldb prompt issue

[Ted Woodward via lldb-dev]

sor(CursorLocation::EditingCursor, CursorLocation::BlockStart);
fprintf(m_output_file, ANSI_CLEAR_BELOW);
}

Then we write the "Stream" content. So after a very long story, you might 
better understand what is happening. It would be worth testing something on 
windows where you just call Debugger::PrintAsync() while the "(lldb) " prompt 
is up and on the screen and see what happens. If this isn't working, then we 
know why the issue is happening. So if you have the following displayed in the 
LLDB driver:

"(lldb) "

And you call "Debugger::PrintAsync("hello world\n", 12, true)" on a thread that 
is not thread 1 from the initial 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

> On Mar 21, 2016, at 10:10 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> 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' (hexagon).
> (lldb) b main
> Breakpoint 1: where = factwin`main + 28 at factorial.c:32, address = 
> 0x5130
> (lldb) r
> Process 1 launched: 'u:\lldb_test\factwin' (hexagon)
> (lldb) Process 1 stopped
> * thread #1: tid = 0x0001, 0x5130 factwin`main(argc=1, argv=0xe110) + 
> 28 at factorial.c:32, stop reason = breakpoint 1.1
> frame #0: 0x5130 factwin`main(argc=1, argv=0xe110) + 28 at 
> factorial.c:32
>29 }
>30   */
>31
> -> 32 base = 10;
>33
>34 printf("Factorial of %d is %d\n", base, factorial(base));
>35 return 0;
>  
>  
> Linux:
> Current executable set to '/usr2/tedwood/lldb_test/factorial' (hexagon).
> (lldb) b main
> Breakpoint 1: where = factorial`main + 28 at factorial.c:32, address = 
> 0x4130
> (lldb) r
> Process 1 launched: '/usr2/tedwood/lldb_test/factorial' (hexagon) 
> Process 1 stopped
> * thread #1: tid = 0x0001, 0x4130 factorial`main(argc=1, argv=0xb100) 
> + 28 at factorial.c:32, stop reason = breakpoint 1.1
> frame #0: 0x4130 factorial`main(argc=1, argv=0xb100) + 28 at 
> factorial.c:32
>29 }
>30   */
>31
> -> 32 base = 10;
>33  
>34 printf("Factorial of %d is %d\n", base, factorial(base));
>35 return 0;
> (lldb)
>  
>  
>  
> Any idea why the prompt is coming out before the stop message?
>  
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>  
> ___
> 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] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

dward 
>>> Cc: LLDB 
>>> Subject: Re: [lldb-dev] "target modules load" and 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:
>>> 
>>> (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 = dlopen`main + 24 at dlopen.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 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 = dlopen`main + 24 at dlopen.c:26, address =
>>>> 0x00030018
>>>> (lldb) gdb-remote tedwood-ubuntu:5556
>>>> 
>>>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>>>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>>>> 0x10018 <  14> send packet: $Z0,10018,4#10
>>>> <   4> read packet: $#00
>>>> Software breakpoints are unsupported <  14> send packet: 
>>>> $Z1,10018,4#11
>>>> <   6> read packet: $OK#9a
>>>> 
>>>> (lldb) br l
>>>> Current breakpoints:
>>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>>> resolved, hit count = 0
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Issue #2: breakpoints on the remote server aren’t updated with a new load 
>>>> address, even though they’re updated in the breakpoint list:
>>>> 
>>>> (lldb) br l
>>>> Current breakpoints:
>>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>>> resolved, hit count = 0
>>>> 
>>>> (lldb) target modules load -f dlopen -s 0x2
>>>> (lldb) br l
>>>> <   7> send packet: $p29#db
>>>> <  12> read packet: $0010#81
>>>> <   7> send packet: $p1d#05
>>>> <  12> read packet: $#80
>>>> Current breakpoints:
>>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
>>>> resolved, hit count = 0
>>>> 
>>>> (lldb) c
>>>> Process 1 stopped
>>>> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1,
>>>> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1  
>>>> frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at
>>>> dlopen.c:26
>>>> 
>>>> (lldb) re r pc
>>>>pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>>>> 
>>>> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 
>>>> 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a 
>>>> Z packet to add one at 0x30018.
>>>> 
>>>> --
>>>> Qualcomm Innovation Center, Inc.
>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>>>> Forum, a Linux Foundation Collaborative Project
>>>> 
>>>> ___
>>>> 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] [Bug 27020] New: "command alias r run" causes an assert

[Ted Woodward via lldb-dev]

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 r is 
an abbreviation for ‘run’. From that help you’d infer that ‘r’ was an 
abbreviation for ‘process launch –c /bin/sh -- -c /bin/sh’.

 

Thanks for the quick fix!

 

Ted

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: egran...@apple.com [mailto:egran...@apple.com] 
Sent: Tuesday, March 22, 2016 4:14 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

 

Ted,

I think this is fixed by r264096

 

Can you try and make sure it works for you?

 

On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

 

 

On Mar 21, 2016, at 2:27 PM, via lldb-dev mailto:lldb-dev@lists.llvm.org> > wrote:

 


Bug ID

27020   


Summary

"command alias r run" causes an assert 


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

ted.woodw...@codeaurora.org   


CC

llvm-b...@lists.llvm.org   


Classification

Unclassified 

 

This happens on Linux and Windows; probably all platforms.
 
>bin/lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) command alias r run
warning: Overwriting existing definition for 'r'.
(lldb) r
CommandAlias::Execute is not to be called
UNREACHABLE executed at
/local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
Abort (core dumped)

 

  _  

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

 

Ted,

unfortunately I am more than a little busy at the moment - and it would 
probably be a day or two before I can actually take a meaningful look at this

 

On the other hand, I suspect I know what the issue you’re running into is

 

Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
function that is responsible for taking an alias apart and passing the pieces 
to the command interpreter for actual execution.

In your case, what is happening is that you have an alias to an alias, so the 
underlying command is actually an alias

 

What one would need to try and do is write a recursive function that, given an 
alias, potentially nested, spits out the final OptionArgVectorSP and non-alias 
CommandObject

It is something I can work on, but as I said, it’s going to be a few days 
before I can get to it. So, if you want to try your hand at a patch to this 
effect, I would be most happy to take a look at it

 

Apologies for the breakage and thanks for reporting this

 

- Enrico

 

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

 


Thanks,

- Enrico
📩 egranata@.com ☎️ 27683

 

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

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

[Ted Woodward via lldb-dev]

"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
Target::CreateProcess, which calls Target::DeleteCurrentProcess, which calls
SectionLoadList::Clear, which erases the section-to-addr mappings.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Tuesday, March 22, 2016 3:51 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working
correctly


> On Mar 22, 2016, at 1:45 PM, Ted Woodward 
wrote:
> 
> 
> This is the code in DynamicLoaderHexagonDYLD.cpp that is loading sections,
with my change to call GetLoadBaseAddress():
> 
>for (unsigned i = 0; i < num_sections; ++i)
>{
>SectionSP section_sp (sections->GetSectionAtIndex(i));
>lldb::addr_t new_load_addr = section_sp->GetFileAddress() +
base_addr;
> 
>if (section_sp->GetLoadBaseAddress(&target) ==
LLDB_INVALID_ADDRESS)
>target.SetSectionLoadAddress(section_sp, new_load_addr);
>}
> 
> But section_sp->GetLoadBaseAddress() always returns LLDB_INVALID_ADDRESS,
even when I set the slide with "target modules load -f dlopen -s 0x2"
and verify that it's there with " image dump sections dlopen", so I'm always
calling SetSectionLoadAddress() with the section's file address.

Step through the code and let me know what isn't working.


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

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

We’re currently still using Python 2.7 and VS 2013 on the Qualcomm Hexagon 
team. We expect to keep pulling from upstream until about the middle of June, 
then branch for a release. We’d rather not switch to Python 3.5/VS 2105 for 
this release.

 

--

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-dev
Sent: Tuesday, March 29, 2016 11:40 AM
To: Aidan Dodds ; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

Keep in mind that llvm bumps minimum vs version roughly once a year, and it's 
probably about that time. So the discussion here is just about whether to do it 
earlier than llvm, not whether to do it all.

So whether it's now or a few months from now, at some point you're going to 
have to handle these incompatibilities in your own fork out of tree

On Tue, Mar 29, 2016 at 9:11 AM Aidan Dodds via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

At Codeplay we are currently building on windows using a split of MSVC
2013 and MSVC 2015.
In theory we are happy to move entirely to 2015, but until then we would
have to work around any 2013 breakages.


On 29/03/2016 16:16, Pavel Labath via lldb-dev wrote:
> Zachary, all,
>
> after overcoming some problems, mostly unrelated to MSVC, we have
> finally managed to switch to VS2015. I think that means there are no
> more VS2013 users remaining. Given that, shall we start the process to
> formally allow c++ features, which were blocked due to VS2013 until
> now? I am mostly thinking about thread-safe function-static variable
> initialization and alias templates here...
>
> what do you think?
> pl
>
>
> On 4 February 2016 at 20:23, Ted Woodward  <mailto:ted.woodw...@codeaurora.org> > wrote:
>> We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
>> that.
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>>
>> -Original Message-
>> From: Pavel Labath [mailto:lab...@google.com <mailto:lab...@google.com> ]
>> Sent: Thursday, February 04, 2016 10:01 AM
>> To: Ted Woodward
>> Cc: Zachary Turner; LLDB
>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
>> toolchain
>>
>> Hi all.
>>
>> we (android lldb team) are starting to transition to VS2015 as well.
>> For now, the plan is to stick to python 2.7, but if we encounter problems 
>> there, the backup plan is to go to python 3 as well. Until then (I estimate 
>> that will take 1--2 weeks) our buildbot 
>> <http://lab.llvm.org:8011/builders/lldb-windows7-android> will continue 
>> building 2.7+2013 and we will be making sure it works, so please don't check 
>> in any VS2013 incompatible code (yet).
>>
>> Ted: If you can't switch to the 3+2015 combination (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
>>
>>
>> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org> > wrote:
>>> No, it turned red Friday night/Saturday morning.
>>>
>>>
>>>
>>> Last good build:
>>>
>>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>>>
>>>
>>>
>>> First bad build:
>>>
>>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>>>
>>>
>>>
>>> It went red because of the change to VS2015/Python 3.5.
>>>
>>>
>>>
>>> --
>>>
>>> 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 <mailto:ztur...@google.com> 
>>> ]
>>> Sent: Tuesday, February 02, 2016 5:28 PM
>>>
>>>
>>> To: Ted Woodward; LLDB
>>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>>> unsupported toolchain
>>>
>>>
>>>
>>> BTW, I expect that your buildbot has been experiencing the problems
>>> wi

[lldb-dev] Get address for PIE-like "process"

[Ted Woodward via lldb-dev]

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, but
all we need is an address. I was thinking of using qShlibInfoAddr, but
that's used to get the address of the link map. Is it ok to use that in the
Hexagon DYLD plugin, or is there a better way to get the data from the stub?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Review of API and remote packets

[Ted Woodward via lldb-dev]

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 address or 
address range. So we implemented tracepoints, which were like breakpoints but 
would turn on/off trace. I'd like to see that kind of support in a trace API.

--
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 Pavel 
Labath via lldb-dev
Sent: Monday, April 11, 2016 9:51 AM
To: Ravitheja Addepally 
Cc: LLDB 
Subject: Re: [lldb-dev] Review of API and remote packets

I think we should reuse packets from the gdb protocol whereever it makes sense. 
So, if they fit your needs (and a quick glance seems to confirm that), then I 
think you should use them.

On 11 April 2016 at 15:28, Ravitheja Addepally  wrote:
> Hello,
>Regarding the packet definitions for tracing, how about reusing 
> the existing btrace packets ?
>
> https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#q
> Xfer%20btrace%20read
>
> On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton  wrote:
>>
>> We also need to think about all other types of tracing. It might make 
>> more sense to keep these calls on SBProcess and have the calls simply be:
>>
>>
>> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions 
>> &trace_options, lldb::SBError &error);
>>
>> And you would need to specify which threads in the SBTraceOptions 
>> object
>> itself?:
>>
>> SBTraceOptions trace_options;
>>
>> And then do some like:
>>
>> trace_options.SetTraceAllThreads();
>>
>> And maybe tracing all threads is the default. Or one can limit this 
>> to one
>> thread:
>>
>> trace_options.SetThreadID (tid);
>>
>> Then you start tracing using the "trace_options" which has the notion 
>> of which threads to trace.
>>
>> lldb::SBError error;
>> lldb::SBTrace trace = process.StartTrace(trace_options, error);
>>
>> It really depends on how all different forms of trace are enabled for 
>> different kinds of tracing. It takes kernel support to trace only 
>> specific threads, but someone might be debugging a bare board that 
>> only has the option tracing all threads on each core. When making an 
>> API we can't assume we can limit this to any threads and even to any process.
>>
>> Greg
>>
>> > On Apr 1, 2016, at 2:00 AM, Pavel Labath  wrote:
>> >
>> > I second Greg's suggestions, and I have some thoughts of my own:
>> >
>> > - with the proposed API, it is not possible to get a trace for 
>> > newly created threads - the process needs to be stopped first, so 
>> > you can enable trace collection. There certainly are cases where 
>> > this could be problematic, e.g. if you get a crash early during 
>> > thread creation and you want to figure out how you got there. For 
>> > this to work, we might need an API like
>> > SBProcess::TraceNewThreads(...)
>> > or
>> > SBProcess::TraceAllThreads(...)
>> > with the assumption that "all" also includes newly created threads 
>> > in the future.
>> >
>> > I'm not saying this needs to be done in the first implementation, 
>> > but I think that we should at least design the API in a way that 
>> > will not make adding this unnecessarily hard in the future (e.g. 
>> > the idea of returning an SBTrace object might be problematic, since 
>> > you don't know if/how many threads will be created).
>> >
>> >
>> >
>> > Also, thinking about new APIs, should we have a way to mark an API 
>> > as incubating/experimental? Maybe it would be good to mark these 
>> > new APIs as experimental for a while, so we have an option of 
>> > changing them in the future, if it turns out we have made the wrong 
>> > decision. I was thinking of either a naming convention
>> > (SBThread::StartTraceExperimental) or some annotation/comment on 
>> > the methods. When we are confident this design is good, we can 
>> > remove the promote the api into the "stable" set.
>> >
>> > pl
>> >
>> >
>> >
>> >
>> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev 
>> >  wrote:
>> >>
>> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev 
>> >>>  wrote:
>> >>>
>> >>> Hello all,
>> >>>  I am currently working on enabling Intel (R) 
>> >>> Processor Trace collection for lldb. I have done some previous 
>> >>> discussions in this mailing list on this topic but just to 
>> >>> summarize , the path we chose was to implement raw trace 
>> >>> collection in lldb and the trace will be decoded outside LLDB. I 
>> >>> wanted to expose this feature through the SB API's  and for trace 
>> >>> data transfer I wish to develop new communication packets. Now I 
>> >>> want to get the new API's and packet specifications reviewed by 
>> >>> the dev list. Please find 

[lldb-dev] odd behavior when source stepping libcxx test - lldb thinks process is running, but never sent a step/resume

[Ted Woodward via lldb-dev]

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 state.

 

The system has 4 threads; only thread 3 is currently being used. The bad
state happens because ProcessGDBRemote::DoResume can't figure out how to
send a resume packet. During the thread plan it resumes all threads. Later
it goes to step thread 3, but it also wants to resume threads 1,2,4, but our
gdbserver doesn't support vCont, so it gives up. I don't think it should be
resuming threads 1,2,4.

 

How can I fix this?

 

The source file is wait.pass.cpp:
https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit
ion/thread.condition.condvar/wait.pass.cpp

 

Disassembly of line 43:

   42   {

-> 43   std::unique_locklk(mut);

   44   std::thread t(f);

->  0x10011c4 <+20>:   { memw(r30+#-20) = r2 }

0x10011c8 <+24>:   { immext(#18198784)

0x10011cc <+28>: r2 = ##18198784 }

0x10011d0 <+32>:   { memw(r30+#-24) = r2 }

0x10011d4 <+36>:   { r2 = memw(r30 + #-20) }

wait.pass.cpp.exe`main + 40 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) at
wait.pass.cpp:43

0x10011d8 <+40>:   { r3 = memw(r30 + #-24) }

wait.pass.cpp.exe`main + 44 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) + 4 at
wait.pass.cpp:43

0x10011dc <+44>:   { memw(r2+#0) = r3 }

wait.pass.cpp.exe`main + 48 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) + 8 at
wait.pass.cpp:43

0x10011e0 <+48>:   { memb(r2+#4)=#1 }

wait.pass.cpp.exe`main + 52 [inlined]
std::__1::unique_lock::unique_lock(std::__1::mutex&) + 12
at wait.pass.cpp:43

0x10011e4 <+52>:   { r0 = memw(r2 + #0) }

0x10011e8 <+56>:   { call 0x1001ab4 }; std::__1::mutex::lock at
mutex.cpp:31

 

The only change-of-flow is the call instruction at the end.

 

 

Select linetable info, from llvm-dwarfdump:

AddressLine   Column File   ISA Discriminator Flags

-- -- -- -- --- - -

0x010011c4 43 33 11   0 0  is_stmt
prologue_end

0x010011d8112 17  3   0 0  is_stmt

0x010011dc112 11  3   0 0 

0x010011e0112 23  3   0 0 

0x010011e4112 38  3   0 0 

0x010011ec 44 17 11   0 0  is_stmt

 

File 11 is wait.pass.cpp; file 3 is __mutex_base, where the inlined
std::unique_lock is defined.

 

Step log:

 

(lldb) r

Process 1 launched: 'c:\lldb\test\cxx11\wait.pass.cpp.exe' (hexagon)

Process 1 stopped

* thread #3: tid = 0x0003, 0x010011c4 wait.pass.cpp.exe`main + 20 at
wait.pass.cpp:43, stop reason = breakpoint 1.1

frame #0: 0x010011c4 wait.pass.cpp.exe`main + 20 at wait.pass.cpp:43

   40

   41   int main()

   42   {

-> 43   std::unique_locklk(mut);

   44   std::thread t(f);

   45   assert(test1 == 0);

   46   while (test1 == 0) {

(lldb) thread list

Process 1 stopped

  thread #1: tid = 0x0001, 0xff004f64

  thread #2: tid = 0x0002, 0xff004f64

* thread #3: tid = 0x0003, 0x010011c4 wait.pass.cpp.exe`main + 20 at
wait.pass.cpp:43, stop reason = breakpoint 1.1

  thread #4: tid = 0x0004, 0xff004f64

(lldb) log enable lldb step

(lldb) s

Finding branch index from address @ 0x010011c4

Instruction @0x010011C4 : 0xA79EE2FB

 

Packet start @0x010011C8

 

Instruction @0x010011C8 : 0x001156C4

 

Instruction @0x010011D0 : 0xA79EE2FA

 

Packet start @0x010011D4

 

Thread::PushPlan(0x04E678D0): "Stepping in through line
wait.pass.cpp:43.", tid = 0x0003.

Process::PrivateResume() m_stop_id = 2, public state: stopped private state:
stopped

Failed to create new thread notification breakpoint.

Thread::PushPlan(0x04E678D0): "Single stepping past breakpoint site
2 at 0x10011c4", tid = 0x0003.

lldb_private::ThreadPlan::WillResume Thread #1 (0x045DDE10): tid =
0x0001, pc = 0xff004f64, sp = 0xff00cb78, fp = 0xff002d10, plan = 'base
plan', state= suspended, stop others = 0

lldb_private::ThreadPlan::WillResume Thread #2 (0x04E660B0): tid =
0x0002, pc = 0xff004f64, sp = 0xff00cc70, fp = 0x, plan = 'base
plan', state= suspended, stop others = 0

lldb_private::ThreadPlan::WillResume Thread #3 (0x04E678D0): tid =
0x0003, pc = 0x010011c4, sp = 0x0525eca8, fp = 0x0525ecf8, plan = 'Step over
breakpoint trap', state = stepping, stop others = 1

lldb_private::ThreadPlan::WillResume Thread #4 (0x04E69080): tid =
0x0004, pc = 0xff004f64, sp = 0xff00ce60, fp = 0x, plan = 'base
plan', state= suspended, stop others = 0

Current Plan for thread 1(045DDE10) (0x0001, suspended): base plan
being asked whether we should report run.

Current Plan for th

Re: [lldb-dev] Redundant six.py copy

[Ted Woodward via lldb-dev]

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-boun...@lists.llvm.org] On Behalf Of Kamil
> Rytarowski via lldb-dev
> Sent: Monday, May 02, 2016 4:36 PM
> To: Reid Kleckner 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Redundant six.py copy
> 
> 
> 
> On 02.05.2016 18:40, Reid Kleckner wrote:
> > On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > It has been noted that LLDB installs its own copy of six.py
> > (third_party/Python/module/six/six.py) that conflicts with a
> standalone
> > one lang/py-six (path in pkgsrc).
> >
> > Could we reuse an external version shipped with a system?
> Alternatively
> > are there plans to migrate to Python 3 and remove need for it?
> >
> > How to address this conflict cleanly?
> >
> >
> > LLDB should continue to ship its own copy of six.py. It's a single 900
> > line source file. Avoiding this duplication is not worth the headache
> > of asking users to install dependencies. I can't imagine a world where
> > checking in your own copy *wasn't* the intended distribution model for
> > six.py.
> >
> 
> I don't agree here, built in libraries have security and maintainability 
> issues
> downstream. Correct packaging is about removing these builtin redundant
> libraries and link with upstream ones. And in case of a vulnerability (or 
> other
> kind of bug) upgrade a dependency for everybody at once.
> 
> > I'm sure LLDB would take patches to mitigate the namespace conflict.
> > For example, LLDB could do something like "from lldbutils import six"
> > instead of "import six", or we could avoid putting it on sys.path if
> > we notice a system installation of six.
> 
> Dynamic detection of system capabilities isn't reproducible. Also there is a
> scenario of installing lldb and later one of other packages installing global 
> py-
> six.


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

Re: [lldb-dev] Redundant six.py copy

[Ted Woodward via lldb-dev]

Should the lldb modules directory be in the global python installation? 
Build/install puts it in /lib/python27 on non-windows hosts.

--
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 Pavel
> Labath via lldb-dev
> Sent: Tuesday, May 03, 2016 4:01 AM
> To: Kamil Rytarowski 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Redundant six.py copy
> 
> We could have a cmake option, say -DUSE_BUILTIN_SIX=true|false (default
> being whatever you like, but I'd like to avoid autodetection, as that can
> produce unexpected results). Distrubution maintainers can set it to false
> (which will prevent six.py from being installed by lldb altogether) and just
> make the lldb package depend on the six package. People who don't want to
> have system dependencies in their shipped version of lldb, can set it to true
> and do what they have done so far...
> 
> pl
> 
> On 3 May 2016 at 02:20, Kamil Rytarowski via lldb-dev  d...@lists.llvm.org> wrote:
> > Having private fallback six.py will work for everybody, just it cannot
> > be installed into the global path along with Python libraries:
> >
> > $ pkg_info -L lldb|grep six.py
> > /usr/pkg/lib/python2.7/site-packages/six.py
> >
> > Maybe in lldb/utils/?
> >
> > chieftec$ pkg_info -L lldb|grep py
> > /usr/pkg/lib/python2.7/site-packages/lldb/__init__.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/_lldb.so
> > /usr/pkg/lib/python2.7/site-packages/lldb/embedded_interpreter.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/formatters/Logger.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/formatters/__init__.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/formatters/attrib_fromdict.p
> > y /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cache.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/__init__.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/gnu_libstdcpp
> > .py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/libcxx.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/formatters/metrics.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/lldb-argdumper
> > /usr/pkg/lib/python2.7/site-packages/lldb/runtime/__init__.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/utils/__init__.py
> > /usr/pkg/lib/python2.7/site-packages/lldb/utils/symbolication.py
> > /usr/pkg/lib/python2.7/site-packages/six.py
> >
> > On 03.05.2016 02:13, Greg Clayton via lldb-dev wrote:
> >> Can we take care of this with python include path ordering? If we are on a
> system that has its own six.py somewhere in the python libraries, how is it
> picking our version incorrectly? 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, then fall back to our
> extra ones in our directories.
> >>
> >> Greg
> >>
> >>> On May 2, 2016, at 4:08 PM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >>>
> >>> 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-boun...@lists.llvm.org] On Behalf
> >>>> Of Kamil Rytarowski via lldb-dev
> >>>> Sent: Monday, May 02, 2016 4:36 PM
> >>>> To: Reid Kleckner 
> >>>> Cc: LLDB 
> >>>> Subject: Re: [lldb-dev] Redundant six.py copy
> >>>>
> >>>>
> >>>>
> >>>> On 02.05.2016 18:40, Reid Kleckner wrote:
> >>>>> On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev
> >>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
> >>>>>
> >>>>>It has been noted that LLDB installs its own copy of six.py
> >>>>>(third_party/Python/module/six/six.py) that conflicts with a
> >>>> standalone
> >>>>>one lang/py-six (path in pkgsrc).
> >>>>>
> >>>>>Could we reuse an external version shipped with a system?
> >>>> Altern

[lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Ted Woodward via lldb-dev]

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 that sets up the inlined function call, run through the inlined
function call, then run to the end of the line. Instead, it runs to the
inlined call, then stops.

 

I'm running lldb on Windows, debugging a Hexagon application that was built
on Linux. I'm using the target.source-map setting to let me see source.

 

The problem is in ThreadPlanStepRange::InRange. It checks to see if we're
still on the same line by comparing the filename in the Stepping Plan's line
entry to the filename in the current frame's line entry.
m_addr_context.line_entry.file has been normalized by the value in
target.source-map, but new_context.line_entry.file hasn't, so they're not
the same, even though they should be.

 

SymbolContext
new_context(frame->GetSymbolContext(eSymbolContextEverything));

if (m_addr_context.line_entry.IsValid() &&
new_context.line_entry.IsValid())

{

if (m_addr_context.line_entry.file ==
new_context.line_entry.file)

{

 

 

Either both should use target.source-map, or neither should.  How do I run
new_context.line_entry.file through the target.source-map normalization?

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Ted Woodward via lldb-dev]

Symbols are being remapped. StackFrame::GetSymbolContext does this:

m_sc.line_entry = sc.line_entry;
if (m_sc.target_sp)
{
// Be sure to apply and file remappings to our file and 
line
// entries when handing out a line entry
FileSpec new_file_spec;
if (m_sc.target_sp->GetSourcePathMap().FindFile 
(m_sc.line_entry.file, new_file_spec))
m_sc.line_entry.file = new_file_spec;
}

This code gets called if the StackFrame ctor is called with the SymbolContext = 
nullptr, but this is skipped if the SymbolContext is valid. All new StackFrames 
in StackFrameList are done with a null SC, except for an inlined frame. In that 
case, StackFrameList::GetFramesUpTo calls 
SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo 
does not remap it like StackFrame::GetSymbolContext does. Then it creates a new 
StackFrame with the SC.

Adding this before the new StackFrame fixes the issue:
if (target_sp)
{
// Be sure to apply and file remappings to our file and 
line
// entries when handing out a line entry
FileSpec new_file_spec;
if 
(target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file, 
new_file_spec))
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 Aurora Forum, a Linux 
Foundation Collaborative 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 Woodward via lldb-dev 
>  wrote:
> 
> I’m stepping over the first line of a libcxx test (source 
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/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 that sets up the inlined function 
> call, run through the inlined function call, then run to the end of the line. 
> Instead, it runs to the inlined call, then stops.
>  
> I’m running lldb on Windows, debugging a Hexagon application that was built 
> on Linux. I’m using the target.source-map setting to let me see source.
>  
> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
> still on the same line by comparing the filename in the Stepping Plan’s line 
> entry to the filename in the current frame’s line entry. 
> m_addr_context.line_entry.file has been normalized by the value in 
> target.source-map, but new_context.line_entry.file hasn’t, so they’re not the 
> same, even though they should be.
>  
> SymbolContext 
> new_context(frame->GetSymbolContext(eSymbolContextEverything));
> if (m_addr_context.line_entry.IsValid() && 
> new_context.line_entry.IsValid())
> {
> if (m_addr_context.line_entry.file == new_context.line_entry.file)
> {
>  
>  
> Either both should use target.source-map, or neither should.  How do I run 
> new_context.line_entry.file through the target.source-map normalization?



It doesn't seem right to me that when symbols are handed out they have the 
source map applied to their file spec's.  After all, then you could get into 
problems like: somebody started a step so we recorded m_addr_context.  Then 
their step was interrupted (say by hitting a breakpoint) and the user added a 
source mapping.  Then we stop in a frame from the same module, and now the 
SymbolContext that the step plan stored (m_addr_context) has a different path 
than the one in the frame when we get to it.  Checking every time you compared 
file specs seems very error prone, we shouldn't do it that way.  I guess if the 
FileSpec == handled this it would be odd but not too bad.  But that seems like 
it would result in a lot of unnecessary work.  I think it would be better to 
only do source map path conversion when sources are looked up, and maybe when 
paths are printed.  For symbols we should stick to what the debug info says.

Jim


>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Ted Woodward via lldb-dev]

Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative 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 Woodward via lldb-dev 
>>>  wrote:
>>> 
>>> I’m stepping over the first line of a libcxx test (source 
>>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/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 that sets up the inlined 
>>> function call, run through the inlined function call, then run to the end 
>>> of the line. Instead, it runs to the inlined call, then stops.
>>> 
>>> I’m running lldb on Windows, debugging a Hexagon application that was built 
>>> on Linux. I’m using the target.source-map setting to let me see source.
>>> 
>>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
>>> still on the same line by comparing the filename in the Stepping Plan’s 
>>> line entry to the filename in the current frame’s line entry. 
>>> m_addr_context.line_entry.file has been normalized by the value in 
>>> target.source-map, but new_context.line_entry.file hasn’t, so they’re not 
>>> the same, even though they should be.
>>> 
>>>   SymbolContext 
>>> new_context(frame->GetSymbolContext(eSymbolContextEverything));
>>>   if (m_addr_context.line_entry.IsValid() && 
>>> new_context.line_entry.IsValid())
>>>   {
>>>   if (m_addr_context.line_entry.file == new_context.line_entry.file)
>>>   {
>>> 
>>> 
>>> Either both should use target.source-map, or neither should.  How do I run 
>>> new_context.line_entry.file through the target.source-map normalization?
>> 
>> 
>> 
>> It doesn't seem right to me that when symbols are handed out they have the 
>> source map applied to their file spec's.  After all, then you could get into 
>> problems like: somebody started a step so we recorded m_addr_context.  Then 
>> their step was interrupted (say by hitting a breakpoint) and the user added 
>> a source mapping.  Then we stop in a frame from the same module, and now the 
>> SymbolContext that the step plan stored (m_addr_context) has a different 
>> path than the one in the frame when we get to it.  Checking every time you 
>> compared file specs seems very error prone, we shouldn't do it that way.  I 
>> guess if the FileSpec == handled this it would be odd but not too bad.  But 
>> that seems like it would result in a lot of unnecessary work.  I think it 
>> would be better to only do source map path conversion when sources are 
>> looked up, and maybe when paths are printed.  For symbols we should stick to 
>> what the debug info says.
>> 
>> Jim
>> 
>> 
>>> 
>>> Ted
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>>> Linux Foundation Collaborative Project
>>> 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Ted Woodward via lldb-dev]

 entry
>>>  FileSpec new_file_spec;
>>>  if (m_sc.target_sp->GetSourcePathMap().FindFile 
>>> (m_sc.line_entry.file, new_file_spec))
>>>  m_sc.line_entry.file = new_file_spec;
>>>  }
>>> 
>>> This code gets called if the StackFrame ctor is called with the 
>>> SymbolContext = nullptr, but this is skipped if the SymbolContext is valid. 
>>> All new StackFrames in StackFrameList are done with a null SC, except for 
>>> an inlined frame. In that case, StackFrameList::GetFramesUpTo calls 
>>> SymbolContext::GetParentOfInlinedScope, which sets the SC, and 
>>> GetFramesUpTo does not remap it like StackFrame::GetSymbolContext does. 
>>> Then it creates a new StackFrame with the SC.
>>> 
>>> Adding this before the new StackFrame fixes the issue:
>>>  if (target_sp)
>>>  {
>>>  // Be sure to apply and file remappings to our file 
>>> and line
>>>  // entries when handing out a line entry
>>>  FileSpec new_file_spec;
>>>  if 
>>> (target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file, 
>>> new_file_spec))
>>>  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 Aurora Forum, a 
>>> Linux Foundation Collaborative 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 Woodward via lldb-dev 
>>>>  wrote:
>>>> 
>>>> I’m stepping over the first line of a libcxx test (source 
>>>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/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 that sets up the inlined 
>>>> function call, run through the inlined function call, then run to the end 
>>>> of the line. Instead, it runs to the inlined call, then stops.
>>>> 
>>>> I’m running lldb on Windows, debugging a Hexagon application that was 
>>>> built on Linux. I’m using the target.source-map setting to let me see 
>>>> source.
>>>> 
>>>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
>>>> still on the same line by comparing the filename in the Stepping Plan’s 
>>>> line entry to the filename in the current frame’s line entry. 
>>>> m_addr_context.line_entry.file has been normalized by the value in 
>>>> target.source-map, but new_context.line_entry.file hasn’t, so they’re not 
>>>> the same, even though they should be.
>>>> 
>>>>  SymbolContext 
>>>> new_context(frame->GetSymbolContext(eSymbolContextEverything));
>>>>  if (m_addr_context.line_entry.IsValid() && 
>>>> new_context.line_entry.IsValid())
>>>>  {
>>>>  if (m_addr_context.line_entry.file == new_context.line_entry.file)
>>>>  {
>>>> 
>>>> 
>>>> Either both should use target.source-map, or neither should.  How do I run 
>>>> new_context.line_entry.file through the target.source-map normalization?
>>> 
>>> 
>>> 
>>> It doesn't seem right to me that when symbols are handed out they have the 
>>> source map applied to their file spec's.  After all, then you could get 
>>> into problems like: somebody started a step so we recorded m_addr_context.  
>>> Then their step was interrupted (say by hitting a breakpoint) and the user 
>>> added a source mapping.  Then we stop in a frame from the same module, and 
>>> now the SymbolContext that the step plan stored (m_addr_context) has a 
>>> different path than the one in the frame when we get to it.  Checking every 
>>> time you compared file specs seems very error prone, we shouldn't do it 
>>> that way.  I guess if the FileSpec == handled this it would be odd but not 
>>> too bad.  But that seems like it would result in a lot of unnecessary work. 
>>>  I think it would be better to only do source map path conversion when 
>>> sources are looked up, and maybe when paths are printed.  For symbols we 
>>> should stick to what the debug info says.
>>> 
>>> Jim
>>> 
>>> 
>>>> 
>>>> Ted
>>>> 
>>>> --
>>>> Qualcomm Innovation Center, Inc.
>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>>>> Linux Foundation Collaborative Project
>>>> 
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>>> 
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 


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

[lldb-dev] bug in TestMiGdbSetShow.test_lldbmi_gdb_set_target_async_off?

[Ted Woodward via lldb-dev]

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

it = self.expect(unexpected + [ "@\"argc=1rn" ])

if it < len(unexpected):

self.fail("unexpected found: %s" % unexpected[it])

 

But lldb-mi does the right thing, expect won't match "running", so the
self.expect command fails, which causes the test to error out. Shouldn't the
self.expect be in a try, with an except being a pass?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Discrete code and data memories

[Ted Woodward via lldb-dev]

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 bus and 1 or more data busses. 56300 was 24 bit, and 
called them p, x and y memories. 56600 had 24 bit p memory and 16 bit x memory. 
And my product at my previous employer took this idea of memory spaces a bit 
farther, and we could use different spaces to access the same memory in 
different ways. So a debugger attached to a Freescale T4240 processor could 
access an address as physical through the SoC, physical/virtual through the 
e6500 PowerPC core (really 1:1 mapping for "physical"), cacheable/non 
cacheable, code/data (code applies the self-modifying code sequence, used 
primarily for software breakpoints). We could combine these options in 
appropriate ways. The memory access functions took a memory space, address, 
size and count.

To implement this in LLDB, we'd need to have a way to decorate a memory range 
with interesting attributes, and a way to get this info over to the remote 
gdb-server.

Duane Ellis talks about some of the issues with supporting this on the GDB 
mailing list: http://comments.gmane.org/gmane.comp.gdb.devel/36147

This actually came up here 2 years ago - 
http://lists.llvm.org/pipermail/lldb-dev/2014-May/004081.html .

Ted

--
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: Wednesday, May 25, 2016 3:57 PM
To: Tyro Software 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Discrete code and data memories

I believe that some of the DSPs we have support for (Hexagon?) has this kind of 
issue. I would speak to Ted Woodward and see if they do anything special for 
this.

Greg Clayton

> On May 25, 2016, at 2:16 AM, Tyro Software via lldb-dev 
>  wrote:
> 
> I'm trying to implement LLDB support for an architecture where code and data 
> stores can be explicitly separated and can even have overlapping addresses 
> (one can think of it as ROM and RAM, with separate access buses). 
> 
> My impression is that LLDB somewhat presumes a hybrid memory map, e.g. the 
> client requests "qMemoryRegionInfo:$PC" for the program counter value but 
> might also do "qMemoryRegionInfo:$SP" for the stack pointer and from the 
> address value alone one can't safely determine which memory type is meant. A 
> similar issue would exist for the X/x commands.
> 
> I apologise for not knowing better terminology to describe this - quite 
> possibly LLDB does cater for it and I haven't understood the description, 
> e.g. there's some way to "adorn" an address or set some context or scope for 
> it through a preceding command?
> 
> Thanks
> /Tyro
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

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

Re: [lldb-dev] LLDB-MI from Eclipse hangs

[Ted Woodward via lldb-dev]

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-continue and –list-thread-groups, 
and send the data that comes out after those.

 

2)  I see from the log that you’re doing a –target-select remote. Are you 
running debugserver manually? What happens if you don’t run debugserver, and 
have Eclipse do –exec-run instead of –target-select remote?

The original Codeplay implementation of lldb-mi talked to the Hexagon 
Simulator, but didn’t have a way to launch it, so they only used –target-select 
remote, and not –exec-run. Debugserver can be launched automatically, so 
–exec-run should work.

 

3)  This is an answer to Greg’s question about –exec-continue and 
–list-thread-groups. I was going to ask the same thing, but I looked over some 
old logs I had. Eclipse called –list-thread-groups while the target was 
running, and it worked fine. This was with a 2 year old lldb-mi, but I’d expect 
a modern lldb-mi to work as well. The spec at 
https://sourceware.org/gdb/onlinedocs/gdb/Thread-groups.html talks about what 
this command does. It gives a list of process groups that the debugger is 
debugging, so it doesn’t matter if a certain process is running or not.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: dipt...@gmail.com [mailto:dipt...@gmail.com] 
Sent: Friday, July 08, 2016 6:23 AM
To: Ted Woodward 
Cc: Greg Clayton ; LLDB 
Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs

 

Thanks Ted for your reply.

I tried the same command that eclipse uses manually from command prompt. It 
hangs after same last command "-exec-continue --thread-group i1". Attached is 
the lldb-mi sample at that time.

 

While debugging from Eclipse I am going to Run--> Debug Configurations--> C/C++ 
Remote Applications-->  and then click on Debug button. And 
then all the commands are executed by Eclipse automatically. I do not see two 
different steps as attach and continue. So I am not sure how to pass command 
"log enable gdb-remote packets". May be I am missing something. Can you please 
help me here, so that I can get the required log as suggested by you? Thanks.

 

 

-- 

Have a nice day!
Regards,
Dipti

On Fri, Jul 8, 2016 at 4:01 AM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

I don’t see anything in the log that looks like a problem. I’ve got 2 thoughts:

 

1)  Have you tried manual debugging with the same sequence that eclipse 
uses? You can copy/paste lines from the log, just remove some extraneous 
logging info, so

313,464 14-file-exec-and-symbols --thread-group i1 
"/Users/admin/Documents/workspace/Hello World C++\

 Project/Debug/Hello World C++ Project"

Becomes

-file-exec-and-symbols --thread-group i1 
"/Users/admin/Documents/workspace/Hello World C++ Project/Debug/Hello World C++ 
Project"

Copy/paste the exact sequence.

 

2)  A packet log after the –list-thread-groups that hangs would be useful. 
After you attach in eclipse, but before you continue, go to the GDB console tab 
and type:

log enable gdb-remote packets

You should get a line in the log that says

-interpreter-exec console “log enable gdb-remote packets”

and then get a giant spew of data after the continue. Please send that data.

 

I worked on getting lldb-mi working with Eclipse for Hexagon; there were times 
when I’d have to copy/paste what Eclipse sent over to replicate problems, and 
bisect those commands to find the combination that caused my bad behavior. You 
may need to do that here.

 

Ted

 

--

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 via lldb-dev
Sent: Thursday, July 07, 2016 10:53 AM
To: Greg Clayton mailto:gclay...@apple.com> >
Cc: lldb-dev@lists.llvm.org  
Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs

 

Thanks Greg for your reply.

 

Attached below is the GDB trace, please let me know if it helps in any ways.

 

It would be helpful if you can tell me on how to capture (I am really new to 
lldb, sorry for bothering you):

- sample lldb-mi to see what it is doing. 

- complete packet log of the traffic between Eclipse and lldb-mi 

 

I am trying with simple "Hello world" c++ program, so libraries should to be a 
problem. Also, same remote debugging is working fine if I manually do it using 
lldb-mi from command prompt. The hang is happening only when I try to do it via 
eclipse. 

 

I am trying via eclipse, because I am looking for some IDE based remote

Re: [lldb-dev] Question about -break-insert in lldb-mi

[Ted Woodward via lldb-dev]

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 Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pierson 
Lee (PIE) via lldb-dev
Sent: Monday, July 11, 2016 1:33 PM
To: jing...@apple.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi

If I don't specify the -f flag (with some random parameter), then a pending 
breakpoint is not created and the initial binding fails. But if I specify the 
-f with the random parameter, then it will bind when the library is loaded. 
This is the behavior I see on gdb also, but sans the random parameter. I looked 
at the source code and can't figure out what it expects the parameter to be and 
what it does with the value. 

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com] 
Sent: Friday, July 8, 2016 7:03 PM
To: Pierson Lee (PIE) 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi


gdb used to try to find a symbol matching the breakpoint specification and if 
it didn't find one immediately, it would raise an error.  If you didn't want 
this behavior (in a world with many shared libraries you seldom did) then you 
could set a "future-break" which is what the -f flag turns on.  This was better 
though a bit bogus, because it would set the breakpoint the FIRST time it took, 
then never look again.

But this was quite a while ago, and I think gdb's gotten better about 
organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
not sure how it works now-a-days.

Anyway, lldb's breakpoints don't work that way.  They stay active till you 
delete them, and keep searching for new matches every time a shared library is 
loaded.  You could make them emulate the gdb behavior by judiciously deleting & 
duplicating breakpoints from the original specification, but there's no way to 
get the native lldb breakpoints to do so (nor should there be IMHO...)

So if you are using the lldb-mi, there's no reason to bother with the -f flag.  
But also lldb-mi should probably just ignore this flag.

Jim
 

> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>  wrote:
> 
> Hi,
>  
> I’m trying to use -break-insert and the -f flag for it. 
>  
> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
> the -f has a required parameter.
>  
> m_setCmdArgs.Add(new 
> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>
> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>  
>  
> Based on the GDB MI documentation (at 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceware.org%2fgdb%2fonlinedocs%2fgdb%2fGDB_002fMI-Breakpoint-Commands.html%23GDB_002fMI-Breakpoint-Commands&data=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8101908d3a79d5c33%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vA0kav9epp3zRa4QivQ9wmimjEHYiJ0AiQfJcGKdzEs%3d)
>  for -break-insert shows:
>  
> ‘-f’
> If location cannot be parsed (for example if it refers to unknown files or 
> functions), create a pending breakpoint. Without this flag, gdb will report 
> an error, and won't create a breakpoint, if location cannot be parsed. 
>  
> Is there a reason why it requires a parameter and what should this parameter 
> be ?
>  
> Thanks
> Pierson
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2flldb-dev&data=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8101908d3a79d5c33%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mCckfTlDjZ8w%2fTvABG6OSj8kZIpC8VeHtjQqHYS8uAk%3d

___
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-MI from Eclipse hangs

[Ted Woodward via lldb-dev]

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. I'd expect an -exec-run to do this 
automatically for you. No need to specify parameters to debugserver.



Here is some of a log of Eclipse talking to lldb-mi talking to a Hexagon 
target. It looks very similar, except for -exec-run instead of -target-select 
remote and -exec-continue:

TX:21-break-insert -t -f main

RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
TX:22-list-thread-groups

RX:(gdb)
RX:21^done,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="0",original-location="main"}
RX:(gdb)
TX:23-exec-run

RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="0",original-location="main"}
RX:(gdb)
RX:22^done,groups=[{id="i1",type="process",executable="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\hexagon_Debug_toolv80_v60/downscaleBy2_q"}]
RX:(gdb)
RX:23^running
RX:=thread-group-started,id="i1",pid="1"
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1e002f38",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="121",pending=["downscaleBy2.c:110"],times="0",original-location="downscaleBy2.c:110"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x1e002df0",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="96",pending=["downscaleBy2.c:96"],times="0",original-location="downscaleBy2.c:96"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="1",original-location="main"}
TX:24-list-thread-groups --available

RX:(gdb)
RX:=thread-created,id="1",group-id="i1"
RX:=thread-created,id="2",group-id="i1"
RX:=thread-created,id="3",group-id="i1"
RX:=thread-created,id="4",group-id="i1"
RX:=thread-selected,id="1"
RX:(gdb)
RX:23^running
RX:=thread-group-started,id="i1",pid="1"
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1e002f38",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="121",pending=["downscaleBy2.c:110"],times="0",original-location="downscaleBy2.c:110"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x1e002df0",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="96",pending=["downscaleBy2.c:96"],times="0",original-location="downscaleBy2.c:96"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="1",original-location="main"}
TX:24-list-thread-groups --available

RX:(gdb)
RX:=thread-created,id="1",group-id="i1"
RX:=thread-created,id="2",group-id="i1"
RX:=thread-created,id="3",group-id="i1"
RX:=thread-created,id="4",group-id="i1"
RX:=threa

Re: [lldb-dev] Question about -break-insert in lldb-mi

[Ted Woodward via lldb-dev]

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 works if a condition is set.

From my reading of the spec at 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html , 
-f should not take a parameter.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] 
Sent: Monday, July 11, 2016 3:59 PM
To: Ted Woodward ; jing...@apple.com; 'LLDB' 

Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi

So the instance I run into the error is setting a conditional breakpoint:

-break-insert -f -c "x==0" main.cpp:13

And I get: 

MI: Error: Command Args. Validation failed. Args missing additional 
information: f ^error,msg="Command 'break-insert'. Command Args. Validation 
failed. Args missing additional information: f"

It seems in the tests/examples, -f is the last parameter and the function/code 
location happens after the -f. 

From my understanding of the MI Command, the -f is a flag that tells it the 
breakpoint is to be set as pending if the debugger cannot determine the 
location of the breakpoint. The optional "parameter" doesn't seem to be used. 

Does this seem like a bug or am I misunderstanding what the -f flag does on 
-break-insert ?

Thanks
Pierson 

-Original Message-
From: Ted Woodward [mailto:ted.woodw...@codeaurora.org]
Sent: Monday, July 11, 2016 1:13 PM
To: Pierson Lee (PIE) ; jing...@apple.com; 'LLDB' 

Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi

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 Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pierson 
Lee (PIE) via lldb-dev
Sent: Monday, July 11, 2016 1:33 PM
To: jing...@apple.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi

If I don't specify the -f flag (with some random parameter), then a pending 
breakpoint is not created and the initial binding fails. But if I specify the 
-f with the random parameter, then it will bind when the library is loaded. 
This is the behavior I see on gdb also, but sans the random parameter. I looked 
at the source code and can't figure out what it expects the parameter to be and 
what it does with the value. 

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com]
Sent: Friday, July 8, 2016 7:03 PM
To: Pierson Lee (PIE) 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi


gdb used to try to find a symbol matching the breakpoint specification and if 
it didn't find one immediately, it would raise an error.  If you didn't want 
this behavior (in a world with many shared libraries you seldom did) then you 
could set a "future-break" which is what the -f flag turns on.  This was better 
though a bit bogus, because it would set the breakpoint the FIRST time it took, 
then never look again.

But this was quite a while ago, and I think gdb's gotten better about 
organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
not sure how it works now-a-days.

Anyway, lldb's breakpoints don't work that way.  They stay active till you 
delete them, and keep searching for new matches every time a shared library is 
loaded.  You could make them emulate the gdb behavior by judiciously deleting & 
duplicating breakpoints from the original specification, but there's no way to 
get the native lldb breakpoints to do so (nor should there be IMHO...)

So if you are using the lldb-mi, there's no reason to bother with the -f flag.  
But also lldb-mi should probably just ignore this flag.

Jim
 

> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>  wrote:
> 
> Hi,
>  
> I’m trying to use -break-insert and the -f flag for it. 
>  
> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
> the -f has a required parameter.
>  
> m_setCmdArgs.Add(new 
> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>
> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>  
>  
> Based on the GDB MI documentation (at 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceware.org%2fgdb%2fonlinedocs%2fgdb%2fGDB_002fMI-Breakpoint-Commands.html%23GDB_002fMI-Breakpoint-Commands&data=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8

Re: [lldb-dev] LLDB Evolution

[Ted Woodward via lldb-dev]

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,

eEnumNameSecondValue,

} EnumName;

   

This redundancy is important because the enumerations that find their way 
through SWIG into Python will show up as lldb.eEnumNameFirstValue, so including 
the enum name in the value name disambiguates them in Python.   
   

 

Some directed questions about this proposal:

-  Will we move to an 80 column limit?

-  Will we move to camel case for variables?

-  Will we stop putting m_ at the front of class ivars and g_ at the 
front of globals?

-  Will we stop using _sp and _up on the end of shared and unique 
pointers?

 

--

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-dev
Sent: Thursday, August 11, 2016 1:37 PM
To: Jim Ingham 
Cc: Kate Stone ; LLDB 
Subject: Re: [lldb-dev] LLDB Evolution

 

I was thinking the same thing too.  I figured this was just for the interim.

 

Chris, did you mean to update the global LLVM style conventions?

 

On Thu, Aug 11, 2016 at 11:27 AM Jim Ingham mailto:jing...@apple.com> > wrote:

Shouldn't this be made general and added to the llvm coding conventions?  I was 
assuming that upon completion of this exercise, we would delete the lldb coding 
conventions doc.

Jim

> On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev 
> mailto:lldb-dev@lists.llvm.org> > wrote:
>
> On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner   > wrote:
>
>> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org> > wrote:
>>
>> So perhaps it would be reasonable for us to standardize on something like 
>> this:
>>
>>  • Main Module Header
>>  • Local/Private Headers
>>  • lldb/...
>>  • llvm/...
>>  • System #includes
>
> This makes sense to me, and matches what clang does as well.  I think that 
> this is clearly in the spirit of the llvm include order standards, and I 
> think it would be great to make this explicit in the coding standard doc.  
> Can you send in a patch to update it to make this explicit?  I’ll review it.
>
> -Chris
>
> I actually just submitted the patch.  (Sorry, itchy trigger finger or 
> something).  r278373.  If you have any comments let me know and I'm happy to 
> iterate on it.
>
> ___
> 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] Linux ELF header e_ident[EI_OSABI] value

[Ted Woodward via lldb-dev]

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 the core file, it will use the OS from the 
target file. For example, I just loaded a Hexagon Linux core file, which lldb 
didn't identify as Linux, and a Hexagon Linux target, which lldb did identify 
as Linux. The final triple is correct - hexagon-*-linux:
(lldb) file u:\hexagon-linux\crash -c u:\hexagon-linux\core
Core file 'u:\hexagon-linux\core' (hexagon) was loaded.
(lldb) tar list
Current targets:
* target #0: u:\hexagon-linux\crash ( arch=hexagon-*-linux, 
platform=remote-linux, pid=13818, state=stopped )


ObjectFileELF::RefineModuleDetailsFromNote looks for a note with type NT_FILE, 
then looks in that for a path that starts with "/lib/x86_64-linux-gnu". If it 
finds that, it will set the core file's OS to Linux. Teaching that to speak the 
Linux dialect you're interested in is probably the right way to go.

--
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, August 22, 2016 11:00 AM
To: Howard Hellyer 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value


> On Aug 22, 2016, at 6:00 AM, Howard Hellyer via lldb-dev 
>  wrote:
> 
> I've been trying to understand why some Linux core files fail to load in 
> lldb. 
> 
> The problem seems to be that in the ELF header Linux uses the ELFOSABI_NONE 
> (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either change the 
> e_ident[EI_OSABI] byte to 0x3 in the header or the code in ArchSpec.cpp to 
> treat ELFOSABI_NONE as Linux then LLDB will open these core files perfectly. 
> The Linux core dumps that are being opened successfully seem to be doing so 
> because lldb is using extra optional information in the notes section. Either 
> because it contains notes “owned” by Linux or because of the file names 
> contained in the FILE note type. A lot of core dumps (it appears to be those 
> created by the kernel following a crash rather than gcore) don’t contain the 
> “LINUX” notes and the file paths in the FILE note can vary a lot by Linux 
> distribution. (For example Ubuntu cores work but Redhat cores I've tried 
> don't as the libraries are in different locations.) 
> 
> Linux doesn't seem to use the ELFOSABIT_LINUX value (0x3) but sticks to the 
> ELFOSABI_NONE (0x0) value. This apppears to be true for both executables and 
> core dumps, LLVM was changed to follow this convention (see: 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301607.html 
> ) but lldb still looks for ELFOSABI_LINUX in ELF headers even though 
> executables and core files seem to contain ELFOSABI_NONE in practise. If I 
> compile code with clang the resulting executable uses ELFOSABI_NONE in the 
> e_ident[EI_OSABI] byte. (If I change the byte manually Linux doesn't appear 
> to care. I think it's probably ignoring the byte.) 
> 
> I'd like to submit a patch to change lldb to treat ELF files with 
> ELFOSABI_NONE set as Linux as a) it would allow lldb to open Linux cores 
> reliably and b) it would match how clang treats e_ident[EI_OSABI]. The code 
> to detect whether lldb is opening a Linux core has changed a lot recently and 
> I don't know the history or if any other ELF platforms leave this byte set to 
> 0x0 in which case this would be confusing, though as this value is currently 
> unused it seems safe. 
> 
> Does anyone know of any reason not to change this? If not I'll submit a patch 
> for review. 

I would change it so that the "os" doesn't get set to anything when it detects 
this in the core file. When an OS is not specified, the llvm::Triple will 
return OSUnknown as the enumeration value for the OS _and_ the llvm::StringRef 
value will return an empty string. This is known in LLDB term as a "unspecified 
unknown". This means the triple will be "x86_64-*-". An unspecified 
unknown is a wildcard. Any plugins that are trying to load a core file should 
watch for this and use it accordingly.

So the answer is not "treat ELF files with ELFOSABI_NONE set as Linux", but 
"treat ELF files with ELFOSABI_NONE set as *". Please submit a patch that 
implements this when you get the chance. Let me know if you have any questions.

Greg Clayton

___
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] Linux ELF header e_ident[EI_OSABI] value

[Ted Woodward via lldb-dev]

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
Linux and Windows, and our core dumps need to work on both.

 

Doesn't lldb get the correct OS from the target when you load them together?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: Howard Hellyer [mailto:hhell...@uk.ibm.com] 
Sent: Friday, August 26, 2016 8:39 AM
To: Todd Fiala 
Cc: LLDB ; Ted Woodward

Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

 

Todd Fiala mailto:todd.fi...@gmail.com> > wrote on
25/08/2016 20:42:31:

> FWIW, I've taken a few whacks at getting Linux detected better over 
> the last few years, and haven't yet found a reliable way to detect 
> it from quite a few samples of cores from a number of different 
> systems.  We can spend more time looking into it, but that stone has
> been turned over several times. 

I spent quite a lot of time looking at the output of readelf too. I was kind
of hoping Linux was the only platform not using it's OSABI value, which
would have worked. 

The only other thing I thought of suggesting was having the ELFOSABI_NONE
case ifdef'd so that lldb defaults to the platform that it was built for -
on the assumption that you are probably opening a core from the machine you
are on. (So on Linux ELFOSABI_NONE would mean Linux, on FreeBSD it would
mean FreeBSD.) That would have meant lldb behaved differently depending on
where it was compiled which seems wrong and would introduce awkward to debug
behaviour so I ended up talking myself out of it. 


Howard Hellyer
IBM Runtime Technologies, IBM Systems 







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

[Ted Woodward via lldb-dev]

After the core file is loaded in ProcessElfCore::DoLoadCore, the logic under 
"target create" will merge the ArchSpec of the target and the core, replacing 
the "unknown" OS in the core ArchSpec with "linux" from the target ArchSpec.

Howard, are you loading a target executable, or just the core?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, August 26, 2016 11:08 AM
To: Ted Woodward 
Cc: Howard Hellyer ; Todd Fiala ; 
LLDB 
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

It is ok for a core file to not pledge allegiance to an OS, it is ok for the OS 
to be set to "*" or any OS. Linux core files are useless without the main 
executable anyway so these two things should used together to do the right 
thing. When creating the core files you use:

lldb::ProcessSP
ProcessElfCore::CreateInstance (lldb::TargetSP target_sp, lldb::ListenerSP 
listener_sp, const FileSpec *crash_file) {

So you are handed the target. You can get the executable 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, 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 Linux 
> and Windows, and our core dumps need to work on both.
>  
> Doesn’t lldb get the correct OS from the target when you load them together?
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>  
> From: Howard Hellyer [mailto:hhell...@uk.ibm.com]
> Sent: Friday, August 26, 2016 8:39 AM
> To: Todd Fiala 
> Cc: LLDB ; Ted Woodward 
> 
> Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
>  
> Todd Fiala  wrote on 25/08/2016 20:42:31:
> 
> > FWIW, I've taken a few whacks at getting Linux detected better over 
> > the last few years, and haven't yet found a reliable way to detect 
> > it from quite a few samples of cores from a number of different 
> > systems.  We can spend more time looking into it, but that stone has 
> > been turned over several times.
> 
> I spent quite a lot of time looking at the output of readelf too. I was kind 
> of hoping Linux was the only platform not using it's OSABI value, which would 
> have worked. 
> 
> The only other thing I thought of suggesting was having the ELFOSABI_NONE 
> case ifdef'd so that lldb defaults to the platform that it was built for - on 
> the assumption that you are probably opening a core from the machine you are 
> on. (So on Linux ELFOSABI_NONE would mean Linux, on FreeBSD it would mean 
> FreeBSD.) That would have meant lldb behaved differently depending on where 
> it was compiled which seems wrong and would introduce awkward to debug 
> behaviour so I ended up talking myself out of it.
> 
> Howard Hellyer
> IBM Runtime Technologies, IBM Systems
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU ___
> 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] Passing std::atomics by value

[Ted Woodward via lldb-dev]

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 Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim Ingham 
via lldb-dev
Sent: Friday, August 26, 2016 2:32 PM
To: Zachary Turner 
Cc: LLDB 
Subject: Re: [lldb-dev] Passing std::atomics by value

That seems to me a compiler bug, not: "You can't pass structures with 
std::atomic" elements in them by value.  It would crazy to add a type to the 
C++ language that you couldn't use everywhere.  There doesn't seem to be any 
official restriction.  And anecdotally there's a reference to the problem in 
gcc for PPC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259) but that was 
considered a bug and fixed.

Not that it matters much, you are stuck with the compiler you're stuck with, 
bugs and all.

Jim

> On Aug 26, 2016, at 12:26 PM, Zachary Turner  wrote:
> 
> It could, in theory, it just doesn't.  I compiled a quick program using 
> i686-darwin as the target and the generated assembly makes no attempt to pad 
> the arguments.
> 
> I'll post some code later
> 
> On Fri, Aug 26, 2016 at 11:42 AM Jim Ingham  wrote:
> 
> > On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > The thing is, the code is already full of data races.  I think the 
> > std::atomic is actually used incorrectly and is not even doing anything.
> >
> > That said, consider darwin on 32-bit, where I believe each stack frame is 
> > 4-byte aligned.  I dont' think there's any way the compiler can guarantee 
> > that a function parameter is 8-byte aligned without allocating from the 
> > heap, which is obviously impossible for a stack variable.
> 
> Why can't the compiler pad the argument slot on the stack so that the actual 
> struct lives at a properly aligned location?  It's copying the value into the 
> callee's stack frame, so it can put it wherever it wants.  And both caller 
> and callee sites know the alignment requirements from the function signature, 
> so they can both figure out where the actual struct lives in the argument 
> slot based on the alignment of the stack slot.
> 
> Jim
> 
> 
> >
> > On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton  wrote:
> >
> > > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev 
> > >  wrote:
> > >
> > >>
> > >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
> > >>  wrote:
> > >>
> > >> I recently updated to Visual Studio 2015 Update 3, which has improved 
> > >> its diagnostics.  As a result of this, LLDB is uncompilable due to a 
> > >> slew of errors of the following nature:
> > >>
> > >> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
> > >> 'default_stop_addr': formal parameter with requested alignment of 8 
> > >> won't be aligned
> > >>
> > >> The issue comes down to the fact that lldb::Address contains a 
> > >> std::atomic, and is being passed by value pervasively 
> > >> throughout the codebase.  There is no way to guarantee that this value 
> > >> is 8 byte aligned.  This has always been a bug, but until now the 
> > >> compiler just hasn't been reporting it.
> > >>
> > >> Someone correct me if I'm wrong, but I believe this is a problem on any 
> > >> 32-bit platform, and MSVC is just the only one erroring.
> > >>
> > >> I'm not really sure what to do about this.  Passing 
> > >> std::atomic's by value seems wrong to me.
> > >>
> > >> Looking at the code, I don't even know why it needs to be atomic.  It's 
> > >> not even being used safely.  We'll have a single function write the 
> > >> value and later read the value, even though it could have been used in 
> > >> the meantime. Maybe what is really intended is a mutex.  Or maybe it 
> > >> doesn't need to be atomic in the first place.
> > >>
> > >> Does anyone have a suggestion on what to do about this?  I'm currently 
> > >> blocked on this as I can't compile LLDB.
> > >
> > > Feel free to #ifdef around the m_offset member of Address and you can 
> > > have the data race and compile. This seems like a compiler bug to me. If 
> > > a struct/classe by value argument has alignment requirements, then the 
> > > compiler should handle this correctly IMHO. Am I wrong
> >
> > Or if this isn't a compiler bug, feel free to modify anything that was 
> > passing Address by value and make it a "const Address &".
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

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

___
lldb-dev mailing 

[lldb-dev] Problem with watchpoints

[Ted Woodward via lldb-dev]

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
packet isn't defined in lldb-gdb-remote.txt.

 

Looking at the code, it expects to get back a pair "num:#". If it doesn't it
returns 0. The caller will report the above error if the number returned is
0. So if qWatchpointSupportInfo isn't supported, lldb can't set a
watchpoint.

 

 

What is the definition of the response to qWatchpointSupportInfo? Is the the
number of supported watchpoints, or the number of available watchpoints? If
it's supported, then CheckIfWatchpointsExhausted won't really check if the
watchpoints are exhausted. If it's available, then a return of 0 doesn't let
us aggregate watchpoints - a 4 byte watchpoint at 0x1000 and one at 0x1004
could be one going from 0x1000-0x1007.

 

 

Wouldn't it be better to try to set the watchpoint, then report a failure if
we get an error back from the remote server?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] Python3 compatibility for the API

[Ted Woodward via lldb-dev]

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/8.1/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
 line 82
except ImportError, e:
  ^
SyntaxError: invalid syntax

If we want to run the tests with Python3 we'll need to update pexpect.

--
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 Luke 
Drummond via lldb-dev
Sent: Tuesday, August 30, 2016 7:01 AM
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Python3 compatibility for the API

Hi Zachary, Peter

On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:
> Right, the existing version that is built and what you are using links 
> directly against a 2.7 libpython at compile time.  So you would 
> probably need to build LLDB from source and tweak the build system to 
> make it possible to link against your 3.x version of python.  There's 
> some build instructions on the website 
> .  I know there's a few linux 
> developers around here, so it's possible someone else would be 
> interested in making this work as well, but I don't know that it's on 
> anyone's immediate timeline.

We build lldb against python3 regularly, because - as Zachary said - this is 
the only way to get scripting support on windows. To link against python3 on 
Linux you *should* just need the correct headers installed, and invoke CMake 
with the correct python path. For Ubuntu:

```
sudo apt install python3-dev
cmake "$PATH_TO_LLVM_SRC" -DPYTHON_EXECUTABLE:FILEPATH=$(which python3) ```

*should* give you everything you need. However, you may see that cmake picks up 
the python3 interpreter correctly, but tries to link against the python2.7 
library.

-- Found PythonInterp: /usr/bin/python3 (found version "3.5.2") [...]
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version 
"2.7.12")

This appears to be due to a problem in LLVM's CMakeLists.txt specifying support 
for 2.7 only. I have a patch to fix the issue awaiting review
[here](https://reviews.llvm.org/D20825) which should fix the issue on Linux 
when multiple pythons are installed. It may be worth applying this patch 
locally and see how you get on.

Hope that helps

Best

Luke
___
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] Problem with watchpoints

[Ted Woodward via lldb-dev]

he concern is duplicating 
> the implementation, I doubt that I could do it if I tried :)
> 
> Duplication of the API should not be an issue either as I plan to 
> strictly adhere to the existing SB api.
> 

That sounds right.

Jim


>> Jim
>> 
>> 
>>> 
>>> \author{Dan}
>>> 
>>> On Fri, Sep 9, 2016 at 3:52 PM, Jim Ingham  wrote:
>>> The main problem with the watchpoint code is that it doesn't share nearly 
>>> as much of the implementation of options and callback handling with the 
>>> breakpoints as it should.  For instance, there's very little need for 
>>> WatchpointOptions and BreakpointOptions to be separate classes, they do 
>>> pretty much exactly the same thing.  If you want to hack on this, the best 
>>> approach I think would be to remove the watchpoint options, and see how far 
>>> you can get using the breakpoint option class.  I bet a lot of goodness 
>>> will fall out of that.  The PerformActions for the StopInfoWatchpoint and 
>>> StopInfoBreakpoint could probably share much of their implementations as 
>>> well.  This is one of those cleanups that's been floating around on all our 
>>> to-do lists for a while now, but keeps getting displaced by other tasks.
>>> 
>>> The BreakpointOptions.h and WatchpointOptions.h files a pretty well 
>>> documented.  That's a fairly good example of how we used to do this.  We 
>>> don't tend to put top-level docs in .cpp files.
>>> 
>>> Jim
>>> 
>>> 
>>>> On Sep 9, 2016, at 2:13 PM, Daniel Noland via lldb-dev 
>>>>  wrote:
>>>> 
>>>> I have also noticed a few problems similar to Ted's and I plan to 
>>>> address them assuming nobody else is already on it.  That said, I 
>>>> am new around here so please bear with me :)
>>>> 
>>>> In fact, I have been hacking on a few watchpoint methods for a 
>>>> while now.  I have implemented some features I personally wanted 
>>>> (specifically callback functions in the SBWatchpoint api).
>>>> 
>>>> I have not yet created a PR (or whatever SVN equivalent) for 
>>>> several reasons (obviously including the big reformat), but mostly 
>>>> I am a bit lost with respect to proper procedure here.  I have gone 
>>>> through the code guidelines for LLVM and LLDB, but I am confused about 
>>>> some things.
>>>> 
>>>> * I have written unit test logic, but I don't really understand the 
>>>> LLDB testing framework.  Also, I understand from other threads that 
>>>> the framework is currently in flux in any case.
>>>> 
>>>> * I have written documentation, but I don't know if what I have 
>>>> written is even desirable.  For 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 
>>>> need to do some research to avoid turning an eventual merge into a big 
>>>> chore.
>>>> 
>>>> * I am pretty unclear on the appropriate way to make my changes 
>>>> work with the Python API.  Should that be on a different PR?  Are 
>>>> we targeting Python 2.7 and 3.{4,5} on all platforms?
>>>> 
>>>> * Do I need to check that the test suite passes on other platforms, 
>>>> or will other devs take care of that?  I don't use OSX or Windows.
>>>> 
>>>> Basically, I would like to help, but more than that I want my 
>>>> "help" to be helpful.
>>>> 
>>>> If somebody who knows what is going on would help me out I would 
>>>> greatly appreciate it.
>>>> 
>>>> \author{Daniel Noland}
>>>> 
>>>> On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
>>>>>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev 
>>>>>>  wrote:
>>>>>> 
>>>>>> 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 no

Re: [lldb-dev] LLDB Evolution - Final Form

[Ted Woodward via lldb-dev]

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 
> assert firing means "You're going to crash *anyway*"

This is emphatically NOT the case.

One of the first tasks I was given when I started at Qualcomm was to fix the 
disassembler for Hexagon. It was a mess - it would assert if the disassembly 
tables couldn't identify an opcode. Maybe that's fine for an assembler, assert 
if you can't generate an opcode, but an unidentified opcode should print a 
warning and move on. It's not a fatal error to disassemble data!

There are other instances of this in llvm. I agree with Greg - libraries 
shouldn't assert.  Send an error back to the caller, and let the caller handle 
it. A typo in my expression that lldb sends to clang shouldn't crash my debug 
session.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

[lldb-dev] LLDB can't find source...but it can?

[Ted Woodward via lldb-dev]

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 have any source. I've got symbols:

(lldb) bt

* thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16,
stop reason = breakpoint 2.1

  * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16

frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124 at
Driver.cpp:150

frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at
Driver.cpp:1350

frame #3: 0x04744384 lldb`__libc_start_main + 48

 

list SBDebugger::Create fails, but list SBDebugger::Create(bool) gives me
source.

(lldb) list SBDebugger::Create

(lldb) list SBDebugger::Create(bool)

File:
\local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger.cpp

   172  return SBDebugger::Create(false, nullptr, nullptr);

   173  }

   174

   175  SBDebugger

   176  SBDebugger::Create(bool source_init_files)

   177  {

   178  return SBDebugger::Create (source_init_files, nullptr, nullptr);

   179  }

   180

   181  SBDebugger

   182  SBDebugger::Create(bool source_init_files, lldb::LogOutputCallback
callback, void *baton)

   183

 

Finally, I try to list based on the address of the function:

(lldb) list 0x114720

error: address resolves to lldb[0x00114720], but there is no line
table information available for this address.

 

But there is line table information for 0x114720 (from llvm-dwarfdump):

0x00114720177  0 80   0 0  is_stmt

0x00114730178 32 80   0 0  is_stmt
prologue_end

0x00114734178 12 80   0 0 

0x00114754178  5 80   0 0

 

 

 

My breakpoint at SBDebugger::Create resolved to prologue_end:

(lldb) break list

Current breakpoints:

1: name = 'main', locations = 1, resolved = 1, hit count = 1

  1.1: where = lldb`main + 32 at Driver.cpp:1335, address = 0x69d0,
resolved, hit count = 1

 

2: name = 'SBDebugger::Create', locations = 3, resolved = 3, hit count = 1

  2.1: where = lldb`lldb::SBDebugger::Create(bool) + 16, address =
0x00114730, resolved, hit count = 1

  2.2: where = lldb`lldb::SBDebugger::Create() + 8, address = 0x001143c0,
resolved, hit count = 0

  2.3: where = lldb`lldb::SBDebugger::Create(bool, void (*)(char const*,
void*), void*) + 40, address = 0x00114404, resolved, hit count = 0

 

 

So - why can LLDB find the source when I specify the function explicitly, or
find the line table info when I set a breakpoint, but not when I am in the
function or list an address?

 

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

[lldb-dev] unaligned cast in TCPSocket::Connect

[Ted Woodward via lldb-dev]

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-aligned loads. I think we need to memcpy the
data into a struct in_addr variable.

 

Anyone have any thoughts on this?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] LLDB can't find source...but it can?

[Ted Woodward via lldb-dev]

> Probably a debug info problem. Before we know to look for addresses within
> a compile unit, the compile unit must claim it has a function that contains 
> this
> address. So check the DWARF in the compile unit that contains 0x114720 (not
> sure if there is a lookup by address in llmv-dwarfdump?) and make sure
> there is a DW_TAG_subprogram that contains this address.
> 
> Greg

I'm changing gears here - I'm having the same issue with lldb-server, and it's 
smaller, so I'm looking at that.

main calls main_gdbserver, which is in tools/lldb-server/lldb-gdbserver.cpp, 
and has no line table info, according to lldb's list comm info.

4: name = 'main_gdbserver', locations = 2
  4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address = 
0x00048964, unresolved, hit count = 0
  4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address = 
0x00048964, unresolved, hit count = 0

(lldb) list 0x48964
error: address resolves to lldb-server[0x00048964], but there is no 
line table information available for this address.


main_gdbserver has a DW_AT_subprogram entry:
0x000306a4:   DW_TAG_subprogram [106] *
DW_AT_low_pc [DW_FORM_addr] (0x00048944)
DW_AT_high_pc [DW_FORM_data4]   (0x0da4)
DW_AT_frame_base [DW_FORM_exprloc]  (<0x1> 6e )
DW_AT_linkage_name [DW_FORM_strp]   ( 
.debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
DW_AT_name [DW_FORM_strp]   ( .debug_str[0x00065792] = 
"main_gdbserver")
DW_AT_decl_file [DW_FORM_data1] 
("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-server/lldb-gdbserver.cpp")
DW_AT_decl_line [DW_FORM_data2] (326)
DW_AT_type [DW_FORM_ref4]   (cu + 0x003b => {0x00011c13})
DW_AT_external [DW_FORM_flag_present]   (true)

And a linetable entry:
0x00048944327  0  1   0 0  is_stmt
0x0004896432811  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 Project

> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Tuesday, 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 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 have any source. I’ve got symbols:
> > (lldb) bt
> > * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16,
> stop reason = breakpoint 2.1
> >   * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
> > frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124 at
> Driver.cpp:150
> > frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at
> Driver.cpp:1350
> > frame #3: 0x04744384 lldb`__libc_start_main + 48
> >
> > list SBDebugger::Create fails, but list SBDebugger::Create(bool) gives me
> source.
> > (lldb) list SBDebugger::Create
> > (lldb) list SBDebugger::Create(bool)
> > File:
> \local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger.cp
> p
> >172  return SBDebugger::Create(false, nullptr, nullptr);
> >173  }
> >174
> >175  SBDebugger
> >176  SBDebugger::Create(bool source_init_files)
> >177  {
> >178  return SBDebugger::Create (source_init_files, nullptr, nullptr);
> >179  }
> >180
> >181  SBDebugger
> >182  SBDebugger::Create(bool source_init_files, lldb::LogOutputCallback
> callback, void *baton)
> >183
> >
> > Finally, I try to list based on the address of the function:
> > (lldb) list 0x114720
> > error: address resolves to lldb[0x00114720], but there is no line
> table information available for this address.
> >
> > But there is line table information for 0x114720 (from llvm-dwarfdump):
> > 0x00114720177  0 80   0 0  is_stmt
> > 0x00114730178 32 80   0 0  is_stmt 
> > prologue_end
> > 0x00114734178 12 80   0 0
> > 0x00114754178  5 80   0 0
> >
> >
> >
> &g

Re: [lldb-dev] LLDB can't find source...but it can?

[Ted Woodward via lldb-dev]

What's the compiler bug? I see a DW_AT_subprogram entry for main_gdbserver, and 
linetable entries for the addresses of main_gdbserver. 

I've found that getting DWARF compiler bugs fixed can be...challenging. The 
better I can narrow it down for the compiler engineers, the better. 

This is clang that was ToT about 2 months ago, BTW.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Monday, October 17, 2016 11:03 AM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] LLDB can't find source...but it can?
> 
> This is a compiler bug.
> 
> > On Oct 14, 2016, at 12:14 PM, Ted Woodward
>  wrote:
> >
> >> Probably a debug info problem. Before we know to look for addresses
> >> within a compile unit, the compile unit must claim it has a function
> >> that contains this address. So check the DWARF in the compile unit
> >> that contains 0x114720 (not sure if there is a lookup by address in
> >> llmv-dwarfdump?) and make sure there is a DW_TAG_subprogram that
> contains this address.
> >>
> >> Greg
> >
> > I'm changing gears here - I'm having the same issue with lldb-server, and
> it's smaller, so I'm looking at that.
> >
> > main calls main_gdbserver, which is in tools/lldb-server/lldb-
> gdbserver.cpp, and has no line table info, according to lldb's list comm info.
> >
> > 4: name = 'main_gdbserver', locations = 2
> >  4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address =
> > 0x00048964, unresolved, hit count = 0
> >  4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address =
> > 0x00048964, unresolved, hit count = 0
> >
> > (lldb) list 0x48964
> > error: address resolves to lldb-server[0x00048964], but there is no
> line table information available for this address.
> >
> >
> > main_gdbserver has a DW_AT_subprogram entry:
> > 0x000306a4:   DW_TAG_subprogram [106] *
> >DW_AT_low_pc [DW_FORM_addr]  (0x00048944)
> >DW_AT_high_pc [DW_FORM_data4](0x0da4)
> >DW_AT_frame_base [DW_FORM_exprloc]   (<0x1> 6e )
> >DW_AT_linkage_name [DW_FORM_strp](
> .debug_str[0x0006577b] = "_Z14main_gdbserveriPPc")
> >DW_AT_name [DW_FORM_strp]( .debug_str[0x00065792] =
> "main_gdbserver")
> >DW_AT_decl_file [DW_FORM_data1]
>   ("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb-
> server/lldb-gdbserver.cpp")
> >DW_AT_decl_line [DW_FORM_data2]  (326)
> >DW_AT_type [DW_FORM_ref4](cu + 0x003b => {0x00011c13})
> >DW_AT_external [DW_FORM_flag_present](true)
> >
> > And a linetable entry:
> > 0x00048944327  0  1   0 0  is_stmt
> > 0x0004896432811  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 Project
> >
> >> -Original Message-
> >> From: Greg Clayton [mailto:gclay...@apple.com]
> >> Sent: Tuesday, 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 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 have any source. I’ve got symbols:
> >>> (lldb) bt
> >>> * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool)
> >>> + 16,
> >> stop reason = breakpoint 2.1
> >>>  * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16
> >>>frame #1: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124
> >>> at
> >> Driver.cpp:150
> >>>frame #2: 0x6aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240

[lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Ted Woodward via lldb-dev]

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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Ted Woodward via lldb-dev]

I think a hardcoded value of 1 for maximum_operations_per_instruction will work 
like it does today – 1 linetable entry per Hexagon packet, which may have 1-4 
instructions in it. Hexagon executes 1 packet at a time, so anywhere from 1-4 
instructions at once.

 

At O0, the compiler doesn’t packetize instructions, so 1 instruction is run at 
a time. At 01 it will, but it doesn’t do many other optimizations. We should 
still have 1 line per packet. O2 and O3 can move instructions around, so will 
have up to 4 source lines in 1 packet. I think we’ll need to experiment 
internally with what that means for the debugger, once we get this change.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Eric Christopher [mailto:echri...@gmail.com] 
Sent: Wednesday, October 19, 2016 6:09 PM
To: Tim Hammerquist 
Cc: Greg Clayton ; Ted Woodward 
; LLDB 
Subject: Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

 

 

On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist mailto:pen...@gmail.com> > wrote:

I was mistaken.

 

The system toolchain builds stage1 llvm, clang & co.

The system toolchain builds lldb containing the llvm/clang/etc bits.

The system toolchain builds gtest test programs. 

The stage1 compiler builds the python test inferiors.

 

 

OK, then it sounds like at least some of the test programs are built with the 
new compiler? IIRC the python test inferiors here are the programs that are the 
meat of the testsuite for lldb yes?

 

If so, then on check-in we should possibly see some difference on some bot if 
they all use the same general configuration.  I don't have a current checkout 
so I don't know if the default -g is used or if it's set to a different dwarf 
level. Currently it looks like clang will use dwarf4 by default with -g:

 

echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o - -target 
x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v clang

0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset = 
0x addr_size = 0x08 (next unit at 0x003b)

 version: 2

 

where the first line is the debug_info header and the second is the version in 
the line table.

 

Ted/Greg: Relatedly, what brought this up was the vliw aspect with 
maximum_operations_per_instruction - it's being hard coded to 1 here and I'm 
not sure how we want to deal with that on hexagon? Currently it'll be hard set 
to 1 so line stepping will work as I imagine it currently does. That said, if 
we wanted to take advantage of it then that's different. Primarily I wasn't 
sure if Ted and folk had a debugger that did take advantage of it if it was 
there.

 

Thanks!

 

-eric

 

 

On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher mailto:echri...@gmail.com> > wrote:

 

On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist mailto:pen...@gmail.com> > wrote:

The LLDB job in  <http://llvm.org/> llvm.org will build a stage1 RA with 
llvm+clang+libcxx+compiler-rt using the system compiler, and use the new 
compiler to build lldb.

 

By default, this is kicked off automatically when a clang stage1 RA is 
successful, but can be manually triggered to build HEAD, or any revision 
desired.

 

The python test suite (invoked with the xcodebuild target 
lldb-python-test-suite) uses the newly built compiler to build its test 
programs.

 

http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4

 

However, the gtest suite (target lldb-gtest) uses the system (Xcode toolchain) 
compiler to build test programs.

 

http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip

 

 

This seems like something that should be fixed :)

 

-eric

 

 

-Tim

 

On Wed, Oct 19, 2016 at 2:36 PM, Eric Christopher mailto:echri...@gmail.com> > wrote:

>From chatting with Tim it sounds like at least one lldb bot uses the ToT 
>compiler - we should probably verify that not only does it use that to build 
>lldb but uses it for the tests. 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, 2016, at 12:19 PM, Ted Woodward via lldb-dev 
> mailto:lldb-dev@lists.llvm.org> > wrote:
>
> 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 mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev

[lldb-dev] "image search-paths add" removes all breakpoints from remote server

[Ted Woodward via lldb-dev]

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. But SetExecutableModule doesn't restore the breakpoints.

 

 

 

This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
Packet log edited to remove chaff.

 

(lldb) log enable gdb-remote packets

(lldb) process launch -s

Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)

(lldb) process status

Process 18766 stopped

* thread #1, name = 'factlin', stop reason = signal SIGSTOP

frame #0: 0x77ddb6b0

->  0x77ddb6b0: movq   %rsp, %rdi

0x77ddb6b3: callq  0x77ddf010

0x77ddb6b8: movq   %rax, %r12

0x77ddb6bb: movl   0x2215ff(%rip), %eax

(lldb) b main

<  15> send packet: $Z0,400586,1#4a

<   6> read packet: $OK#9a

Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586

(lldb) br l

Current breakpoints:

1: name = 'main', locations = 1, resolved = 1, hit count = 0

  1.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 0 

(lldb) image search-paths add /local /tmp

<  15> send packet: $z0,400586,1#6a

<   6> read packet: $OK#9a

<  15> send packet: $z0,400410,1#5c

<   6> read packet: $OK#9a

(lldb) br l

Current breakpoints:

1: name = 'main', locations = 1

  1.1: where = factlin`main + 22 at factorial.c:32, address =
factlin[0x00400586], unresolved, hit count = 0 

(lldb) c

<   5> send packet: $c#63

Process 18766 resuming

Factorial of 10 is 3628800

<   7> read packet: $W00#b7

Process 18766 exited with status = 0 (0x)

 

As you can see, the breakpoint at main was removed on lldb-server, but shows
as active in the breakpoint list. When I continue, the breakpoint isn't hit,
and the target runs to completion.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server

[Ted Woodward via lldb-dev]

I tried having SetExecutableModule call ModuleDidLoad after appending the 
executable to m_images, but it didn't work. It eventually drills down to call 
GetSectionLoadList, which is empty. Probably because the module list got 
cleared. Any thoughts on how to clean up the new module list, and add the 
breakpoints back?

That leads me to think that other modules besides the executable would just be 
lost.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> 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, 2016, at 12:03 PM, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > 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. But SetExecutableModule doesn’t restore the
> breakpoints.
> >
> >
> >
> > This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
> Packet log edited to remove chaff.
> >
> > (lldb) log enable gdb-remote packets
> > (lldb) process launch –s
> > Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
> > (lldb) process status
> > Process 18766 stopped
> > * thread #1, name = 'factlin', stop reason = signal SIGSTOP
> > frame #0: 0x77ddb6b0
> > ->  0x77ddb6b0: movq   %rsp, %rdi
> > 0x77ddb6b3: callq  0x77ddf010
> > 0x77ddb6b8: movq   %rax, %r12
> > 0x77ddb6bb: movl   0x2215ff(%rip), %eax
> > (lldb) b main
> > <  15> send packet: $Z0,400586,1#4a
> > <   6> read packet: $OK#9a
> > Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
> > 0x00400586
> > (lldb) br l
> > Current breakpoints:
> > 1: name = 'main', locations = 1, resolved = 1, hit count = 0
> >   1.1: where = factlin`main + 22 at factorial.c:32, address =
> > 0x00400586, resolved, hit count = 0
> > (lldb) image search-paths add /local /tmp <  15> send packet:
> > $z0,400586,1#6a
> > <   6> read packet: $OK#9a
> > <  15> send packet: $z0,400410,1#5c
> > <   6> read packet: $OK#9a
> > (lldb) br l
> > Current breakpoints:
> > 1: name = 'main', locations = 1
> >   1.1: where = factlin`main + 22 at factorial.c:32, address =
> > factlin[0x00400586], unresolved, hit count = 0
> > (lldb) c
> > <   5> send packet: $c#63
> > Process 18766 resuming
> > Factorial of 10 is 3628800
> > <   7> read packet: $W00#b7
> > Process 18766 exited with status = 0 (0x)
> 
> This is a distinction without much difference, but the break list output is
> actually telling you somebody forgot to re-install the breakpoints.  Note the
> state went from resolved (i.e. there is a site in the targeted process for 
> this
> breakpoint location) to unresolved.  Still a bug, but the breakpoints aren't
> lying to you...
> 
> When you added search paths, all the breakpoints needed to be re-set, since
> the symbol world might have changed.  But apparently only the removal part
> is getting done.
> 
> Jim
> 
> 
> >
> > As you can see, the breakpoint at main was removed on lldb-server, but
> shows as active in the breakpoint list. When I continue, the breakpoint isn’t
> hit, and the target runs to completion.
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> > ___
> > 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-3.8.1 prebuilt binary for windows7

[Ted Woodward via lldb-dev]

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, and PYTHON_HOME to my 
python installation (on our buildbots, c:/python351).

 

#2 only needs to be solved if the machine you’re running on doesn’t have the 
same python installation, in PYTHON_HOME above. To do that, I’ve added code to 
set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro down to 
InitializePythonHome in 
source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and call 
Py_SetPythonHome with it. My installations have the python dll and python 
library directory. We put the library in /lib/python35 and the dll in 
/bin.

--

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: Wednesday, November 23, 2016 12:40 PM
To: Vadim Chugunov 
Cc: Reid Kleckner ; Hans Wennborg ; LLDB 
; Ted Woodward 
Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

 

I believe the way to fix this is going to be building LLDB for the installer 
with LLDB_RELOCATABLE_PYTHON=1 at CMake time

 

+Ted, since I believe he is one of the few people currently using this flag.

On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

This is still broken in the October snapshot.   Do you know which script is 
used to build the Windows installer?

 

On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

I think it is a problem with the way we built lldb.  I will look into what 
additional steps we need to take when making the prebuilt binary so that it 
works next time.

 

On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

Nope, that didn't help.

 

On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

I may know what this is.  Can you try setting PYTHONPATH though to point to 
your Python 3.5 installation though and see if it fixes it?  (I don't think it 
will, but let's try anyway)

 

On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the 
'site-packages' directory does not exist.  Nor do I see '_lldb.pyd' anywhere 
else.  

'script import lldb' also fails, of course.

 

On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

He said he did, so I don't know.  Vadim, can you elaborate?  When you run `lldb 
-P` from the command line, what do you see?

 

On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

I imagine that Hans doesn't have Python 3 installed on his system, so LLDB 
didn't autoconfigure with Python support.

 

On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

> Does the 4.0 binary not work for you? It is the first release that contains 
> prebuilt lldb binary. 

 

Looks like the Python API is not included though.   Do you know why it was left 
out?

 


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

 

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

 

 

 

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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Ted Woodward via lldb-dev]

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 problem it solves is “where is my python?” on Windows. If you know you’ll 
be running on a system with the same python installation as the build system, 
then you don’t need it. Or if you can tell your users to install the same 
python you built with, in the same location, you’re OK. I can’t do that, so 
instead I ship python, and tell lldb where to find it at build time.

 

We copy over the full site-packages directory that is created by the lldb 
build, and end up with this directory structure:

bin/lldb.exe

bin/liblldb.dll

bin/python35.dll

lib/python35

lib/site-packages

 

--

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: Monday, November 28, 2016 12:17 PM
To: Vadim Chugunov ; Hans Wennborg 
Cc: Ted Woodward ; Reid Kleckner 
; LLDB 
Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

 

I overlooked that part of it, but yes that is another separate issue.  (BTW, 
_lldb.pyd is simply a symlink to liblldb.dll).  

 

In any case, yea I think the entire lib/site-packages folder needs to be 
included.

 

On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

Please correct me if I'm wrong, but isn't the issue here that LLDB's Python 
support files don't get packaged into the Windows installer?   Does packaging 
them somehow depend on knowing what the Python installation path is?

 

On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg mailto:h...@chromium.org> > wrote:

The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.

I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.

On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner mailto:ztur...@google.com> > wrote:
> So it sounds like you're saying that in order for Python support to work as
> part of an LLDB shipped in the installer, we need to do set 3 variables at
> CMake time.
>
> 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> 2) -DPYTHON_HOME = 
> 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>
> Now because of #3, the lldb shipped in the installer will use the PYTHONHOME
> system environment variable to locate python, which must point to a valid
> Python 3.5 installation.  Is this correct?
>
> On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward   >
> wrote:
>>
>> 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, and PYTHON_HOME to my
>> python installation (on our buildbots, c:/python351).
>>
>>
>>
>> #2 only needs to be solved if the machine you’re running on doesn’t have
>> the same python installation, in PYTHON_HOME above. To do that, I’ve added
>> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro
>> down to InitializePythonHome in
>> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
>> call Py_SetPythonHome with it. My installations have the python dll and
>> python library directory. We put the library in /lib/python35 and
>> the dll in /bin.
>>
>> --
>>
>> 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: Wednesday, November 23, 2016 12:40 PM
>> To: Vadim Chugunov mailto:vadi...@gmail.com> >
>> Cc: Reid Kleckner mailto:r...@google.com> >; Hans Wennborg 
>> mailto:h...@chromium.org> >;
>> LLDB mailto:lldb-dev@lists.llvm.org> >; Ted 
>> Woodward mailto:ted.woodw...@codeaurora.org> >
>> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>
>>
>>
>> I believe the way to fix this is going to be building LLDB for the
>> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>
>>
>>
>> +Ted, since I believe he is one of the few people currently using this
>> flag.
>>
>> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov >  > wrote:
>>
>> This is still broken in the October snapshot.   Do you know which script
>> is used to build the Windows installer?
>>
>>
>>
>> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner >  >
>> wrote:
>>
>> I think it is a problem with the way we built lldb.  I will look into what
>> additional 

Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7

[Ted Woodward via lldb-dev]

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


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eli
> Zaretskii via lldb-dev
> Sent: Tuesday, December 06, 2016 10:39 AM
> To: Zachary Turner 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
> 
> > From: Zachary Turner 
> > Date: Tue, 06 Dec 2016 16:22:51 +
> >
> > I have never seen either of those problems, but I can test it out and see 
> > if I
> can reproduce.
> 
> Thanks.
> 
> If you are unable to reproduce, I wonder why it happens to me.  The system
> where I installed lldb is just a vanilla Windows 7 box.
> ___
> 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 bare-metal and 'load' command

[Ted Woodward via lldb-dev]

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 remote server and platform do 
that, it should handle what you need.

Ted

--
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 Abid,
> Hafiz via lldb-dev
> Sent: Friday, December 16, 2016 11:00 AM
> To: Greg Clayton (gclay...@apple.com) 
> Cc: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] LLDB bare-metal and 'load' command
> 
> Hi Greg,
> I was trying to do some bare-metal debugging with LLDB and an ARM board. I
> noticed that LLDB does not have a command similar to 'load' command of
> GDB. Searching the mailing list, it seems that this issue has been discussed
> before.
> 
> http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html
> 
> Has any such command been added in LLDB since that discussion? If not,
> then I would like to take a stab at adding this command in LLDB proper. I was
> wondering where such command will make most sense. Should it be added
> to some existing group like 'process' or 'image' or be a stand-alone
> command?
> 
> Thanks,
> Abid
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] test decorator working on linux, but not on windows

[Ted Woodward via lldb-dev]

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.exe, and this decorator is
evidently not firing, because the test fails instead of being xfailed.

 

Linux is using Python 2.7.8. Windows is using Python 3.5.1.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

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

Re: [lldb-dev] test decorator working on linux, but not on windows

[Ted Woodward via lldb-dev]

Bottom line: lldbutil.is_exe() does not think “foo” is an exe on windows when 
“foo.exe” is.

 

 

 

print("***compiler is:", self.getCompiler(), file=sys.stderr)

 

***compiler is: 
C:\lldb\8.0\llvm\tools\lldb\packages\Python\lldbsuite\test\lang\c\typedef

 

self.getCompiler() is returning the test directory.

 

So, _decorateTest’s line:

skip_for_compiler = _match_decorator_property(compiler, 
self.getCompiler()) and self.expectedCompilerVersion(compiler_version)

is trying to match with the test directory.

 

On Linux I get this:

***compiler is: 
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/toolset-4199/Tools/bin/clang-3.9

The path to the compiler (hexagon-clang is a symlink to clang-3.9).

 

Builder_base.getCompiler is:

def getCompiler():

"""Returns the compiler in effect the test suite is running with."""

compiler = os.environ.get("CC", "clang")

compiler = lldbutil.which(compiler)

return os.path.realpath(compiler)

 

os.environ.get returns 
r:/internal/branch-8.0/windows/latest/Tools/bin/hexagon-clang, but 
lldbutil.which returns None.

def which(program):

"""Returns the full path to a program; None otherwise."""

fpath, fname = os.path.split(program)

if fpath:

if is_exe(program):

return program

else:

for path in os.environ["PATH"].split(os.pathsep):

exe_file = os.path.join(path, program)

if is_exe(exe_file):

return exe_file

return None

 

The problem is the compiler – I specified hexagon-clang, not hexagon-clang.exe, 
so is_exe returns false.

def is_exe(fpath):

"""Returns True if fpath is an executable."""

return os.path.isfile(fpath) and os.access(fpath, os.X_OK)

 

 

 

My run line:

c:\lldb\8.0\35\Debug\libexec\python_d dotest.py -A v60 -C 
r:/internal/branch-8.0/windows/latest/Tools/bin/hexagon-clang --executable 
c:\lldb\8.0\35\Debug\bin\lldb.exe -t -v -p Testtypedef.py

 

Changing it to hexagon-clang.exe solved the problem.

 

 

--

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: Friday, January 06, 2017 12:17 PM
To: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] test decorator working on linux, but not on windows

 

You will probably need to debug the python code to figure out why this is 
happening.  Start with this line in 
lldb/packages/Python/lldbsuite/test/decorators.py

def _decorateTest(mode,

  bugnumber=None, oslist=None, hostoslist=None,

  compiler=None, compiler_version=None,

  archs=None, triple=None,

  debug_info=None,

  swig_version=None, py_version=None,

  macos_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> > wrote:

packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this decorator:

 

@expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238 
<http://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.exe, and this decorator is 
evidently not firing, because the test fails instead of being xfailed.

 

Linux is using Python 2.7.8. Windows is using Python 3.5.1.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto: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] Prebuilt binary for Windows

[Ted Woodward via lldb-dev]

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.

 

 

 

--

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 Vadim 
Chugunov via lldb-dev
Sent: Wednesday, January 11, 2017 8:49 PM
To: Zachary Turner 
Cc: LLDB 
Subject: Re: [lldb-dev] Prebuilt binary for Windows

 

 

 

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

Ahh, that would make sense as well, since LLDB links against liblldb as a dll.  
Don't see a good solution to this short of forcing dynamic linking.  liblldb 
has to be a dll because it needs to be visible to python as an extension 
module.  And if it's a dll and uses static linking, then we would have to 
require that lldb.exe not pass file handles across the dll boundary.  If that's 
easy then great, but I suspect it probably isn't.  

 

Honestly dynamic linking was created to solve exactly these kinds of problems.  
Yes there's the redist issue if on Windows < 10, but it seems like a small 
price to pay for something that doesn't have weird subtle bugs.  And as time 
goes on, more and more people will be on windows 10 anyway.

 

Does the redistributable issue present a challenge for your use case?

 

There are actually two part of the MSVC runtime: the Universal C Runtime (UCRT) 
and the compiler-specific, VCRUNTIME140.   The former is widely available 
(comes with Windows 10, and had been pushed to Vista, 7 and 8 via Windows 
Update).  The latter is tied to the compiler version and must still be 
redistributed with programs.   Ideally, LLDB would use dynamic UCRT + static 
VCRUNTIMExx.  Unfortunately this doesn't seem to be a supported configuration 
(discussion of this issue in Python bug tracker 
 ).   Looks like Python folks opted for 
shipping VCRUNTIME140.DLL in their install directory.

 

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

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

[Ted Woodward via lldb-dev]

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 Of Eugene
Birukov via lldb-dev
Sent: Friday, January 20, 2017 12:35 PM
To: Pavel Labath 
Cc: rd...@microsoft.com; LLDB 
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

 

Hello Pavel,

 

Thanks for the reply. Unfortunately I cannot share the core dump with you.

 

Yes, Rob has figured that LLDB does not find this shared library and that
causes the problem. To understand what is going on here, I need to add one
more detail that was missing from my original post: this is a cross-machine
investigation. I.e. the core dump collected on one machine (CentOs) was sent
to another

(Ubuntu) where I tried to open it.

 

LLDB opens the executable without paying attention that there is a core dump
attached and tries to locate shared libraries. Apparently the ones that
exist on my machine are not good, so it then looks in the directory with the
executable itself. There is no way to "set solib-search-path" as we do on
GDB and force it to look somewhere else. After we dumped all the shared
libraries in the folder with the executable LLDB was able to open the dump.
This is a bit inconvenient, but works as a workaround for now.

 

Sent from Outlook  

 

  _  

From: Pavel Labath mailto:lab...@google.com> >
Sent: Friday, January 20, 2017 6:55 AM
To: Eugene Birukov
Cc: LLDB; rd...@microsoft.com  
Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump 

 

Hello Eugene,

I have been aware of this problem for a while, but I haven't found a
really good solution so far, partially due to lack of a good repro
case -- I think your analysis has helped me with this, and I am
finally starting to piece together the sequence of events leading to
the crash. If you have a repro case you can send me, it would be even
better.

I don't really have an answer to your quesiton, but here are a couple
of observations (the details might be a bit sketchy - it's been a long
time since I looked at this):
- reading the section headers from memory should be a fallback.
Normally we try first to locate the file on disk and read data from
there. This was mainly added for the vdso "module", as that is not
really present on disk. One of the ways of fixing this crash could be
to figure out why we are not finding the c++abi binary on disk.

- we trust far too much the data we read from inferior memory. We
should be much more careful when doing things based on "untrusted"
data. Checking the memory maps as you suggest could be one idea.
Another option I am considering is teaching ReadMemory to allocate
data in (reasonably sized, say a couple of MB) chunks. Right now it
allocates the full buffer without even trying to read the memory. If
it instead tried to read data in smaller chunks it would error out due
to failure to read inferior memory long before it gets a chance to
exhaust own address space. (With a sufficiently large chunk, this
should not affect performance of normal reads).

hope that helps,
pl



On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
> Hi,
>
>
> I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> greatly appreciate any advise how to deal with the problem or what else I
> should look at.
>
>
> The core dump was produced by GDB and GDB itself opens it without
problems.
>
>
> So, during loading the core we call
> DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> modules and does some processing. In the course of actions, it calls the
> ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> load section headers and read string table. Well, it gets some garbage in
> the section header struct and tries to allocate 1.5TB memory which causes
> operator new throw.
>
>
> So, why we get garbage?
>
>
> The module in question is libc++abi.so.1:
>
>
> 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> I->link_addr, I->base_addr, true);
>
> (gdb) p I->file_spec
>
> $95 = {
>
>   m_directory = {
>
> m_string = 0x829a58 "... redacted ..."
>
>   },
>
>   m_filename = {
>
> m_string = 0x7cc9e8 "libc++abi.so.1"
>
>   },
>
>   m_is_resolved = false,
>
>   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
>
> }
>
>
> The module header lives at address 0x7f699a27  and looks OK. The
section
> headers are supposed to be at offset 2495600 == 0x261470
>
>
> $96 = (const elf::ELFHeader &) @0x953a78: {
>
>   e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
>
>   e_entry = 33392,
>
>   e_phoff = 64,
>
>   e_shoff = 2495600,
>
>   e_flags = 0,
>
>   e_version = 1,
>
>   e_type = 3,
>
>   e_machine = 62,
>
>   e

[lldb-dev] non-stop mode with lldb-mi?

[Ted Woodward via lldb-dev]

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

 

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

Re: [lldb-dev] non-stop mode with lldb-mi?

[Ted Woodward via lldb-dev]

That turns on and off async, but not non-stop.

 

I’m working on adding support for –gdb-set and –gdb-show non-stop, and will 
post my changes on phabricator when I’m done.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Ilia K [mailto:ki.s...@gmail.com] 
Sent: Wednesday, February 01, 2017 11:13 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] non-stop mode with lldb-mi?

 

Please check `-gdb-set target.async` option. Probably that's what you need.

 

On Thu, 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. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 


___
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> 
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev





 

-- 

- Ilia

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

Re: [lldb-dev] non-stop mode with lldb-mi?

[Ted Woodward via lldb-dev]

I'm working on plumbing the existing non-stop mode switch 
(target.non-stop-mode) to lldb-mi, to give Eclipse access to non-stop mode.

The remote OS is very thread-heavy, and the remote stub doesn't limit the 
debugger to the current process - because there isn't one, from the stub's 
point of view. Just a collection of threads. In all-stop mode, if a 2nd thread 
hits a breakpoint, it will send back a 2nd stop reply, which confuses lldb 
(rightly so). In non-stop mode, it handles things correctly. So we'll just have 
to live with the possible missed breakpoint issue.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Friday, February 03, 2017 10:58 AM
> To: Greg Clayton 
> Cc: Ted Woodward ; LLDB  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> 
> 
> > On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > Non-stop mode is a huge change to the core of LLDB isn’t it. I think you
> might think this is easier than it actually is to enable in LLDB?
> >
> > Is non-stop mode where you can leave some threads running while others
> are stopped? The biggest issue with this is to do it right we need to be able 
> to
> emulate instructions so that if 3 threads hit breakpoints, we would need to
> emulate the instruction that used to be at the breakpoint in LLDB since we
> can’t remove the breakpoint (unless you stop the other threads which
> defeats the purpose of non-stop mode) without the other 2 threads possibly
> missing the breakpoint while you disable breakpoint, single step, enable
> breakpoint.
> 
> That is just one of the many things that will have to be changed to support
> non-stop mode.  For now, non-stop 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 is it has some utility - presumably you're using it because
> you have some threads in your program that can't stop, so you're not likely 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.llvm.org> wrote:
> >>
> >> That turns on and off async, but not non-stop.
> >>
> >> I’m working on adding support for –gdb-set and –gdb-show non-stop,
> and will post my changes on phabricator when I’m done.
> >>
> >> --
> >> Qualcomm Innovation Center, Inc.
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora
> Forum, a Linux Foundation Collaborative Project
> >>
> >> From: Ilia K [mailto:ki.s...@gmail.com]
> >> Sent: Wednesday, February 01, 2017 11:13 PM
> >> To: Ted Woodward 
> >> Cc: LLDB 
> >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> >>
> >> Please check `-gdb-set target.async` option. Probably that's what you
> need.
> >>
> >> On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev  d...@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. is a member of Code Aurora
> Forum, a Linux Foundation Collaborative Project
> >>>
> >>>
> >>> ___
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>>
> >>
> >>
> >>
> >> --
> >> - Ilia
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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

Re: [lldb-dev] non-stop mode with lldb-mi?

[Ted Woodward via lldb-dev]

I think the remote stub only sends extra stop replies in response to a vStopped 
packet. Here is a stop for 2 threads hitting a common breakpoint:

<  51> send packet: $vCont;c:10b6;c:10f8;c:00b3;c:00b2;c:00b1;c:00b0#e0
<   1> read packet: +
<   6> read packet: $OK#9a
<   1> send packet: +
<  58> read packet: %Stop:T052a:c8f4f5e0;1e:90de101b;1d:48dd101b;thread:af;#1d
<   1> send packet: +
<  12> send packet: $vStopped#55
<   1> read packet: +
<  53> read packet: $T052a:c8f4f5e0;1e:309c101b;1d:e89a101b;thread:b0;#d8
<   1> send packet: +
<  12> send packet: $vStopped#55
<   1> read packet: +
<   6> read packet: $OK#9a

So we won't get any spurious stops in the middle of processing.

"Experimental feature, not tested" is noted - I'll mention that in my meeting 
today.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Friday, February 03, 2017 1:22 PM
> To: Ted Woodward 
> Cc: Greg Clayton ; LLDB 
> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> 
> 
> > On Feb 3, 2017, at 10:51 AM, Ted Woodward
>  wrote:
> >
> > I'm working on plumbing the existing non-stop mode switch (target.non-
> stop-mode) to lldb-mi, to give Eclipse access to non-stop mode.
> >
> > The remote OS is very thread-heavy, and the remote stub doesn't limit the
> debugger to the current process - because there isn't one, from the stub's
> point of view. Just a collection of threads. In all-stop mode, if a 2nd thread
> hits a breakpoint, it will send back a 2nd stop reply, which confuses lldb
> (rightly so). In non-stop mode, it handles things correctly. So we'll just 
> have
> to live with the possible missed breakpoint issue.
> 
> We tried to keep the possibility of a non-stop mode in mind when designing
> lldb, but I know there are places in lldb at present that assume that if you 
> get
> a "stop" event you won't get another stop event till lldb issues a run.  We 
> try
> not to fall over completely if we get events we don't expect, but we're more
> likely to just discard them than do the right thing.  There also don't appear 
> to
> be any tests running programs in non-stop mode and exercising their
> behavior, so any extent to which it works will be accidental and unstable.
> 
> Seems like this is an experimental feature at best, and should be marked as
> such.
> 
> Jim
> 
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >
> >> -Original Message-
> >> From: jing...@apple.com [mailto:jing...@apple.com]
> >> Sent: Friday, February 03, 2017 10:58 AM
> >> To: Greg Clayton 
> >> Cc: Ted Woodward ; LLDB  >> d...@lists.llvm.org>
> >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> >>
> >>
> >>> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Non-stop mode is a huge change to the core of LLDB isn’t it. I think
> >>> you
> >> might think this is easier than it actually is to enable in LLDB?
> >>>
> >>> Is non-stop mode where you can leave some threads running while
> >>> others
> >> are stopped? The biggest issue with this is to do it right we need to
> >> be able to emulate instructions so that if 3 threads hit breakpoints,
> >> we would need to emulate the instruction that used to be at the
> >> breakpoint in LLDB since we can’t remove the breakpoint (unless you
> >> stop the other threads which defeats the purpose of non-stop mode)
> >> without the other 2 threads possibly missing the breakpoint while you
> >> disable breakpoint, single step, enable breakpoint.
> >>
> >> That is just one of the many things that will have to be changed to
> >> support non-stop mode.  For now, non-stop 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 is it has some utility - presumably you're using
> >> it because you have some threads in your program that can't stop, so
> >> you're not likely to want them to hit breakpoints anyway...  B

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Ted Woodward via lldb-dev]

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 image of threads within
>> debuggee]
>>  - Resume Thread 2 (PT_RESUME)
>>  - Suspend Thread 3 (PT_SUSPEND)
>>  - Set single-step Thread 2 (PT_SETSTEP)
>>  - Set single-step Thread 4 (PT_SETSTEP)
>>  - Clear single-step Thread 5 (PT_CLEARSTEP)
>>  - Resume & emit signal SIGIO (PT_CONTINUE)
>>
>> In other words: setting properties on threads and pushing the
>> PT_CONTINUE button at the end.

> None of this is really NetBSD-specific, except the whole-process signal at 
> the end (which I am going to ignore for now). I mean, the implementation of 
> it is different, but there is no reason why someone would not want to perform 
> the same set of actions on Linux for instance. I think most of the work here 
> should be done on the client. Then, when the user issues the final 
> "continue", the client sends something like $vCont;s:2;s:4;c:5. Then it's up 
> to the server to figure out how execute these actions. On NetBSD it would 
> execute the operations you mention above, while on linux it would do 
> something like ptrace(PTRACE_SINGLESTEP, 2); ptrace(PTRACE_SINGLESTEP, 4); 
> ptrace(PTRACE_CONTINUE, 5); (linux lldb-server already supports this 
> actually, although you may have a hard time convincing the client to send a 
> packet like that).

The big problem with this sequence is non-stop mode. To continue thread 5 while 
threads 2 and 4 are stepping, and thread 3 is stopped is not legal using 
all-stop mode. lldb only supports non-stop mode in the gdb-remote 
communications layer; the guts of the debugger do not support it, and could get 
very confused when threads 2 and 4 stop, but thread 5 is still running.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

[lldb-dev] std::vector formatter question

[Ted Woodward via lldb-dev]

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 vector.c:10
   7vector v;
   8v.push_back(2);
   9v.push_back(1);
-> 10   cout << v[0] << " " << v[1] << endl;
   11   return 0;
   12   }
 (lldb) fr v v
(std::vector >) v = size=0 {}

When I run on x86 linux built with gcc, I get:
(lldb) fr v v
(std::vector >) v = size=2 {
  [0] = 2
  [1] = 1
}


My guess is Dinkumware's vector type is just a little bit different from
libstdc++/libcxx, so the standard formatters don't do the right thing. Where
are the vector formatters defined, and how does LLDB determine which
one to use?


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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

Re: [lldb-dev] Using LLDB API on windows

[Ted Woodward via lldb-dev]

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 a call that 
eventually gets to  GDBRemoteCommunication::StartDebugserverProcess to start up 
lldb-server. On Windows, PlatformWindows::DebugProcess calls Process::Launch, 
which (on Windows) will do the correct thing to start up and connect to a 
Windows process.

 

See PlatformWindows::DebugProcess in 
source\Plugins\Platform\Windows\PlatformWindows.cpp and 
ProcessLauncherWIndows::LaunchProcess in 
source\Host\windows\ProcessLauncherWindows.cpp .

 

Ted

 

--

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 Russell 
Greene via lldb-dev
Sent: Sunday, April 02, 2017 4:38 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Using LLDB API on windows

 

Hey so I am developing a project using LLDB as a debugger and am looking to 
make it cross-platform. 

 

As I see it, the LLDB API boots up an instance of lldb-server, but lldb-server 
isn't available on windows. Is there a way to use the LLDB C++ API on windows? 

 

On the status page   I see the lldb 
commandline tool is OK for windows, which uses the LLDB API, how is this 
achieved?

 

-Russell

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

Re: [lldb-dev] Using LLDB API on windows

[Ted Woodward via lldb-dev]

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, a Linux 
Foundation Collaborative Project

 

From: Russell Greene [mailto:russellgree...@gmail.com] 
Sent: Monday, April 03, 2017 11:24 AM
To: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] Using LLDB API on windows

 

That makes sense, and I'm sure it works great when using MSVC as a compiler, 
but I think LLDB recognizes mingw as a unix compiler and tries to do 
GDBRemoteCommunication::StartDebugserverProcess when it should be doing 
PlatformWindows::DebugProcess. 

 

Not sure though. All I know is when I try to do a SBTarget::Launch on windows 
under mingw (msys2) it says cannot find lldb-server...

 

-Russell

 

On Mon, Apr 3, 2017 at 9:32 AM Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

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 a call that 
eventually gets to  GDBRemoteCommunication::StartDebugserverProcess to start up 
lldb-server. On Windows, PlatformWindows::DebugProcess calls Process::Launch, 
which (on Windows) will do the correct thing to start up and connect to a 
Windows process.

 

See PlatformWindows::DebugProcess in 
source\Plugins\Platform\Windows\PlatformWindows.cpp and 
ProcessLauncherWIndows::LaunchProcess in 
source\Host\windows\ProcessLauncherWindows.cpp .

 

Ted

 

--

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 Russell Greene via 
lldb-dev
Sent: Sunday, April 02, 2017 4:38 PM
To: lldb-dev@lists.llvm.org  
Subject: [lldb-dev] Using LLDB API on windows

 

Hey so I am developing a project using LLDB as a debugger and am looking to 
make it cross-platform. 

 

As I see it, the LLDB API boots up an instance of lldb-server, but lldb-server 
isn't available on windows. Is there a way to use the LLDB C++ API on windows? 

 

On the status page   I see the lldb 
commandline tool is OK for windows, which uses the LLDB API, how is this 
achieved?

 

-Russell

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

[lldb-dev] remote server crash -> lldb waits forever in accept()

[Ted Woodward via lldb-dev]

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 that the simulator
can't handle. In this case the simulator quits before connecting to lldb,
and lldb will wait forever for the connection, since TCPSocket::Accept has
no timeout.

Currently I have a select call before the accept, to make sure there is
activity on the socket. This doesn't feel right with the new changes using
MainLoop, so I wanted to see what the list thinks. I believe it will happen
any time that debugserver/lldb-server quits or crashes before connecting.
That should be easy to test.

This is what I use, right before the call to accept_loop.Run in
TCPSocket::Accept:

NativeSocket accept_socket = -1;
fd_set readset;
FD_ZERO(&readset);
for (auto socket : m_listen_sockets) {
  auto fd = socket.first;
  FD_SET(fd, &readset);
  if (fd > accept_socket)
accept_socket = fd;
}
struct timeval timeout = {10, 0};
int result = ::select(accept_socket + 1, &readset, NULL, NULL,
&timeout);
if (result == 0) {
  printf("error: timeout waiting for remote server to connect!\n");
  error.SetErrorString("timeout waiting for remote server to connect");
  return error;
} else if (result < 0) {
  printf("error: remote server does not exist!\n");
  SetLastError(error);
  return error;
}


Any thoughts this issue?

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project



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

Re: [lldb-dev] Python scripting in Windows LLDB

[Ted Woodward via lldb-dev]

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 1 PARENT_SCOPE)

return()

  endif()

 

Internally I’ve changed it to:

 

  if (CMAKE_BUILD_TYPE STREQUAL "Debug")

if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))

  message("Python installation is corrupt. Python support will be disabled 
for this build.")

  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

  return()

endif()

  else()

if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))

  message("Python installation is corrupt. Python support will be disabled 
for this build.")

  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

  return()

endif()

  endif()

 

That works with our buildbots building release.

 

Note the release check doesn’t check for the DLL – our installations don’t have 
the release DLL, so I didn’t put that in.

 

I can push this change upstream if you’d like, Zach.

 

--

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-dev
Sent: Friday, May 19, 2017 3:18 PM
To: Vadim Chugunov ; Hans Wennborg ; LLDB 

Subject: Re: [lldb-dev] Python scripting in Windows LLDB

 

Hmm, I believe it's only supposed to do that if you're doing a debug build.  It 
should only require the Python libraries that match your current build.  Is it 
not doing this?

 

On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

Update: looks like Python detection in CMake now requires debug binaries to be 
there as well (e.g. python35_d.dll), otherwise Python support gets disabled.  I 
am wondering if Python the build machine was installed without the debug stuff.

 

On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

Hi!

 

I've just noticed that LLDB from the most recent LLVM Windows snapshot build 
has Python scripting disabled. 

Was this done on purpose and for what reason if so?

 

___
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] Python scripting in Windows LLDB

[Ted Woodward via lldb-dev]

My dev machine has both debug and release python exe/lib/dll installed; The VS 
solution made by cmake works fine building debug and release versions of lldb. 
Our bots only have release exe/lib, and create a VS solution with cmake and 
build with msbuild.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Monday, May 22, 2017 3:47 AM
> To: Ted Woodward 
> Cc: Zachary Turner ; Vadim Chugunov
> ; Hans Wennborg ; LLDB  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Python scripting in Windows LLDB
> 
> This may cause some issues with the multi-configuration generators.
> E.g. a single VS build will create both debug and release configurations. I
> suspect this is the reason 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:
> > 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 1 PARENT_SCOPE)
> >
> > return()
> >
> >   endif()
> >
> >
> >
> > Internally I’ve changed it to:
> >
> >
> >
> >   if (CMAKE_BUILD_TYPE STREQUAL "Debug")
> >
> > if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND
> > PYTHON_DEBUG_DLL))
> >
> >   message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> >   set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> >   return()
> >
> > endif()
> >
> >   else()
> >
> > if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))
> >
> >   message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> >   set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> >   return()
> >
> > endif()
> >
> >   endif()
> >
> >
> >
> > That works with our buildbots building release.
> >
> >
> >
> > Note the release check doesn’t check for the DLL – our installations
> > don’t have the release DLL, so I didn’t put that in.
> >
> >
> >
> > I can push this change upstream if you’d like, Zach.
> >
> >
> >
> > --
> >
> > 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-dev
> > Sent: Friday, May 19, 2017 3:18 PM
> > To: Vadim Chugunov ; Hans Wennborg
> > ; LLDB 
> > Subject: Re: [lldb-dev] Python scripting in Windows LLDB
> >
> >
> >
> > Hmm, I believe it's only supposed to do that if you're doing a debug build.
> > It should only require the Python libraries that match your current build.
> > Is it not doing this?
> >
> >
> >
> > On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev
> >  wrote:
> >
> > Update: looks like Python detection in CMake now requires debug
> > binaries to be there as well (e.g. python35_d.dll), otherwise Python
> > support gets disabled.  I am wondering if Python the build machine was
> > installed without the debug stuff.
> >
> >
> >
> > On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov 
> wrote:
> >
> > Hi!
> >
> >
> >
> > I've just noticed that LLDB from the most recent LLVM Windows snapshot
> > build has Python scripting disabled.
> >
> > Was this done on purpose and for what reason if so?
> >
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >

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

Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"

[Ted Woodward via lldb-dev]

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 system in /local/scratch/work/debuglibs , you can say
target modules search-paths add /usr/lib /local/scratch/work/debuglibs
and when lldb goes to load (for example) /usr/lib/libc.so, it will try to load 
/local/scratch/work/debuglibs/libc.so from the host machine before trying to 
load through the memory interface.

I found this very helpful when trying to debug dynamic executables on Linux 
running on a Hexagon board, running lldb on x86 Linux or Windows.

Ted

--
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 Jim
> Ingham via lldb-dev
> Sent: Monday, May 22, 2017 5:02 PM
> To: Chunseok Lee 
> Cc: lldb-dev 
> Subject: Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"
> 
> In general, if lldb can find host-side copies of binaries that match the ones 
> it
> finds on the device, it will do all symbol reading against the host copies.  
> In
> the case of an OS X host debugging iOS, lldb uses Spotlight and a few other
> tricks to find the host-side binaries.  You can also use "add-symbol-file" to
> manually point lldb at the host-side symbol files.  If you are reading symbols
> from host-side files, then symbol loading doesn't slow down debugging
> startup that much.
> 
> Presumably, your symbol files are only on the device, so you are reading
> them from memory.  "settings set target.memory-module-load-level" is
> almost what you want, but it applies to ALL shared libraries read from
> memory.  If you can copy the symbol file that contains the
> __jit_debug_register_code to the host you are debugging from, and use
> add-symbol-file to tell lldb about it, then that one should NOT have to be
> read from memory anymore.  Then you could turn "memory-module-load-
> level" to partial or even mininal, and that should get you starting faster.
> 
> The other option would be to extend the setting, so you can say:
> 
> set set target.memory-module-load-level [[lib-name level] [lib-name level]
> ...]
> 
> If there's just one argument, that's equivalent to "all ".
> 
> Jim
> 
> > On May 22, 2017, at 2:35 PM, Chunseok Lee 
> wrote:
> >
> >
> >
> > Thank you for your help.
> > It would be really helpful to me.
> >
> > The reason behind the question is exactly what you mentioned. I am
> > wokring on debugging in devices and it seems that shared library loading(I
> do not know lldb loads symbols lazyly) runs very slowly since my testing
> program depends on so many shared libs.  since I am debuggging with gdbjit
> feature, I do not need shared library loading except one shared lib(which
> contains __jit_debug_register_code symbol) Thus, I want to turn off shred
> lib loading except one shared lib. Is it possible?
> >
> > Thank you.
> >
> > BR,
> > Chunseok Lee
> >
> >
> >
> > 2017. 5. 23. 오전 3:24 Jim Ingham  작성:
> >
> >> We designed lldb to be as lazy as possible in loading symbol information
> from the shared libraries as they get loaded.  If this is causing you 
> problems,
> the first thing to do is to figure out why lldb is pulling in more information
> than you need.  For instance, it looks like on Linux the gdb JIT loading
> breakpoint is getting set with a global search which is pulling in all the 
> symbols
> from all the initially loaded shared libraries.  It would be better to fix 
> things so
> that only explicit user actions (which can be scoped to shared libraries to 
> limit
> the search) pull in symbols so we don't have to fiddle around with turning off
> and on the loading of shared libraries.  Back when we were supporting gdb
> for MacOS I did a lot of work to try to get this right (there are times you 
> really
> need the shared library info - e.g. when something shows up in a backtrace)
> so you have to judiciously re-introduce symbols, or the user experience is
> noticeably degraded.
> >>
> >> It also depends on how far you want to go turning this off.  There's "don't
> look at shared libraries at all" which is what the auto-solib-add variable 
> does
> IIRC.  We also had a fairly extensive mechanism to specify "load-levels" for
> various libraries, which  was more user-friendly but much more work to
> support.  Anyway, it would be easy to just turn this shared library
> notifications - just don't set the dyld load notification breakpoint.  That 
> would
> be the easy part.  But as I said above, you're also going to have to make sure
> you turn it back on for users when some action they request requires it.
> >>
> >> Note, there is a setting to determine how much symbol information to
> read in from l

Re: [lldb-dev] Documentation LLDB-MI

[Ted Woodward via lldb-dev]

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) for 
-file-exec-and-symbols, I don’t see a way to read a core file with mi commands, 
but you can give an lldb command that will be passed through, something like 
“target create foo.elf -c foo.core”

 

You build lldb-mi the same way you build lldb, just use the lldb-mi target. For 
example, “make lldb-mi”.

 

--

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 Laghzaoui 
Mohammed via lldb-dev
Sent: Friday, May 26, 2017 5:43 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Documentation LLDB-MI

 

Hi Lists,

I have to implement a graphical interface to open the Dump of Macos with LLDB.

I know how to do this using the command line, but this and less productive, I 
found that LLDB-MI little make me an interface to do this need but I did not 
find an example of LLDB-MI in C ++ and How to build LLDB-MI.

To detail our need:

1 - opening of a core dump.

2 -__ reading the value of a memory address.

3 -__ list threads and frames.

4 -__ get assembler of each frame.

  

Thank you in advance for your help

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

[lldb-dev] issue with lldb-mi -var-update with pointers

[Ted Woodward via lldb-dev]

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, 2, 3, 4};
  int foo = 0;
  int *bar = &foo;
  int i = 0;

  for (i = 0; i < 4; i++)
*bar += vec[i];

  return foo;
}

Commands:
-break-insert -t -f test.c:10
-break-insert -t -f test.c:13
-exec-run
-var-create --thread 1 --frame 0 - * bar
-var-list-children var0
-var-evaluate-expression var0.*bar
-exec-continue
-var-update 1 var0
-var-evaluate-expression var0.*bar


Output:
(gdb)
-var-create --thread 1 --frame 0 - * bar
^done,name="var0",numchild="1",value="0x7fffed30",type="int
*",thread-id="1",has_more="0"
(gdb)
-var-list-children var0
^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numchild="0"
,type="int",thread-id="1",has_more="0"}],has_more="0"
(gdb)
-var-evaluate-expression var0.*bar
^done,value="0"

***Value is 0

(gdb)
-exec-continue
^running
(gdb)
=thread-exited,id="1",group-id="i1"
(gdb)
*running,thread-id="all"
(gdb)
=thread-created,id="1",group-id="i1"
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={level="0",addr
="0x00400530",func="main",args=[],file="test.c",fullname="/local/scr
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
(gdb)
-var-update 1 var0
^done,changelist=[]

***No changes

(gdb)
-var-evaluate-expression var0.*bar
^done,value="10"

***Value is 10, even though we reported no changes.

The child shows an update:
(gdb)
-var-update 1 var0.*bar
^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_changed=
"false",has_more="0"}]


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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

Re: [lldb-dev] issue with lldb-mi -var-update with pointers

[Ted Woodward via lldb-dev]

Yes, please fix the first problem.

Thanks!

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: Abid, Hafiz [mailto:hafiz_a...@mentor.com]
> Sent: Wednesday, May 31, 2017 7:09 AM
> To: Ted Woodward 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] issue with lldb-mi -var-update with pointers
> 
> I see 2 problems here. CMICmdCmdVarUpdate::ExamineSBValueForChange
> seems to ignore the changes in in children for pointer and references. It
is
> easy enough to fix. The other issue is that we dont not print the changed
> child value.
> For example, with the first issue fixed, I get
> 
> -var-update 1 var0
> ^done,changelist=[{name="var0",value="0x7fffed30",in_scope="tru
> 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
> 
> From: lldb-dev  on behalf of Ted
> Woodward via lldb-dev 
> Sent: Tuesday, May 30, 2017 9:50 PM
> To: 'LLDB'
> Subject: [lldb-dev] issue with lldb-mi -var-update with pointers
> 
> 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, 2, 3, 4};
>   int foo = 0;
>   int *bar = &foo;
>   int i = 0;
> 
>   for (i = 0; i < 4; i++)
> *bar += vec[i];
> 
>   return foo;
> }
> 
> Commands:
> -break-insert -t -f test.c:10
> -break-insert -t -f test.c:13
> -exec-run
> -var-create --thread 1 --frame 0 - * bar -var-list-children var0
-var-evaluate-
> expression var0.*bar -exec-continue
>  1 var0
> -var-evaluate-expression var0.*bar
> 
> 
> Output:
> (gdb)
> -var-create --thread 1 --frame 0 - * bar
> ^done,name="var0",numchild="1",value="0x7fffed30",type="int
> *",thread-id="1",has_more="0"
> (gdb)
> -var-list-children var0
> ^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numch
> ild="0"
> ,type="int",thread-id="1",has_more="0"}],has_more="0"
> (gdb)
> -var-evaluate-expression var0.*bar
> ^done,value="0"
> 
> ***Value is 0
> 
> (gdb)
> -exec-continue
> ^running
> (gdb)
> =thread-exited,id="1",group-id="i1"
> (gdb)
> *running,thread-id="all"
> (gdb)
> =thread-created,id="1",group-id="i1"
> (gdb)
> *stopped,reason="breakpoint-
> hit",disp="del",bkptno="2",frame={level="0",addr
> ="0x00400530",func="main",args=[],file="test.c",fullname="/local/s
> cr
>
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
> (gdb)
> -var-update 1 var0
> ^done,changelist=[]
> 
> ***No changes
> 
> (gdb)
> -var-evaluate-expression var0.*bar
> ^done,value="10"
> 
> ***Value is 10, even though we reported no changes.
> 
> The child shows an update:
> (gdb)
> -var-update 1 var0.*bar
> ^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_ch
> anged=
> "false",has_more="0"}]
> 
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> 
> ___
> 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] Support for Error Strings in remote protocol

[Ted Woodward via lldb-dev]

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 always be optional.

--
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 Pavel
> Labath via lldb-dev
> Sent: Wednesday, June 21, 2017 11:41 AM
> To: Ravitheja Addepally 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Support for Error Strings in remote protocol
> 
> +1 one from me. I like the idea a lot. Specific details below.
> 
> On 21 June 2017 at 16:31, Ravitheja Addepally via lldb-dev  d...@lists.llvm.org> wrote:
> > Hello all,
> >Currently the remote protocol in LLDB does not allow sending
> > Error Strings in response to remote packets, it only allows for "ENN"
> > format where N is a hex integer. In our current ongoing work, we would
> > like to have support for Sending Error Strings from lldb-server. I
> > would like to invite any opinions or suggestions in this matter ?
> >
> > A very simple proposal would be to just attach an error string maybe
> > as a Name:Value Pair ? like so ->
> >
> > EXX;"Error String"
> >  or
> > EXX;M"Error String"
> 
> I guess the decision here depends on how forward-compatible we want to
> be. If we don't anticipate adding further fields here, then the format can 
> just
> be EXX;message and no quoting is needed. If we want to add more fields in
> the future (I don't really see what could they be though), then we should
> stick to the standard semi-colon delimited list  format. So, something like:
> EXX;message:
> But then we need to decide how to encode . I guess the most
> "standard" approach would be to hex-encode it, although it will make them
> hard to read manually.
> 
> >
> > I guess removing EXX would make it incompatible with gdb-server. Also
> > adding new packets to query errors might not be desired ?
> I think we should keep the numeric codes. Sometimes it may be useful to
> programmatically switch on them, and that's hard to do with a string only. For
> compatibility's sake, I'd only send the error messages if the client 
> explicitly
> enables it via some packet.
> 
> pl
> ___
> 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] Python scripting in Windows LLDB

[Ted Woodward via lldb-dev]

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 (which 
contains dlls/sos) than what was used when building lldb. MacOS and various 
Linux distros ship with a fixed version of python, so lldb can be built with 
that version. Windows doesn’t have a default python, so you need to make sure 
that your user has the same version of python that lldb was built with.

 

For the Hexagon tools, we ship the python dll/so and the library directory that 
we built with. We use 3.5.1 on Windows, and 2.7.8 on Linux. On Linux, we set 
RPATH to ../lib, so lldb/liblldb.so can find libpython.so. On both, we set a 
cmake variable LLDB_DEFAULT_PYTHONHOME, and use it when initializing python to 
point lldb to the path where our python library is installed. This code isn’t 
upstreamed, but I can upstream it if the community would like it.

 

Another issue on Windows is the python installation integrity check in 
cmake/modules/LLDBConfig.cmake. It checks to see if python is installed 
correctly like 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 1 PARENT_SCOPE)

return()

  endif()

 

 

If you don’t have the debug version of python installed (as is the case on our 
builders), this check will fail, and python will be turned off. Internally, I 
break this check up into debug and release checks, based on the value of 
CMAKE_BUILD_TYPE. I also don’t check for the release dll, because our builders 
don’t have that.  I can also upstream this if the community is interested.

 

Ted

 

--

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 Jamie 
Madill via lldb-dev
Sent: Thursday, June 29, 2017 10:30 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Python scripting in Windows LLDB

 

A ping for this regression - Ted Woodward seems to have had a patch for fixing 
broken Windows scripting support but the 5.0.0 snapshot release didn't have the 
fix. Is it possible to land that patch for the next snapshot?

 

This is currently breaking LLDB Visual Studio Code integration on Windows (for 
context, see https://github.com/vadimcn/vscode-lldb/issues/37 .)

 

Thanks!

Jamie

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

Re: [lldb-dev] Python scripting in Windows LLDB

[Ted Woodward via lldb-dev]

I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 
.so/library directory, so I’m not willing to say building on Windows with 3.6.1 
and using the 3.5.2 dll/library directory will work. Python has never been very 
forgiving when using a different setup than what you built with.

 

My point with that statement is you’ve got to make sure the runtime environment 
matches the build environment, something harder to do on Windows where there is 
no default runtime environment.

 

--

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: Friday, June 30, 2017 3:05 PM
To: Ted Woodward ; Jamie Madill 
; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Python scripting in Windows LLDB

 

 

On Fri, Jun 30, 2017 at 12:39 PM 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, crashes, etc – 
when you use a different rev of the dll/so or the library directory (which 
contains dlls/sos) than what was used when building lldb. 

This is no longer true right?  That was one of the major drivers behind moving 
to Python 3.5.  All that matters is 

 

a) The build configuration matches (if LLDB was built against Python debug, you 
must have debug libraries available)

b) The architecture matches (if it's an x64 build of LLDB, you need x64 Python 
libraries)

c) The version is 3.5 or higher.

 

Aside from that it shouldn't matter

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

Re: [lldb-dev] Trying to use socketpair for lldb-server fails

[Ted Woodward via lldb-dev]

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 variables:
LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will
be written to
LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn
logging on for. The format is "channel category:channel category...". If you
want more than 1 category for a channel, I think "channel cat1 cat2..."
works. This is not spelled out very clearly, unfortunately.


Quickly glancing at the code, it looks like you need to implement a
socketpair connection, and handling of the fd:// connection URL, starting in
ConnectionFileDescriptor::Connect. The log for this would be "lldb
connection".

Ted

--
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 Demi
> Obenour via lldb-dev
> Sent: Wednesday, July 19, 2017 7:44 PM
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] Trying to use socketpair for lldb-server fails
> 
> To avoid a local privilage escalation, I am trying to patch LLDB not to
use a TCP
> socket for local communication.
> 
> The attached patch failed.  Would anyone be able to provide suggestions
for
> how to debug the problem?
> 
> Sincerely,
> 
> Demi

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

Re: [lldb-dev] Trying to use socketpair for lldb-server fails

[Ted Woodward via lldb-dev]

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

 

From: Demi Obenour [mailto:demioben...@gmail.com] 
Sent: Friday, July 21, 2017 8:54 PM
To: Ted Woodward ; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Trying to use socketpair for lldb-server fails

 

Sadly, that gives me nothing in the log file.  Also, 
ConnectionFileDescriptor::Connect already seems to handle this case.

 

Running strace on all child processes gives a “Operation not permitted” error 
from setsid().  That seems like the culprit, which is strange.

 

Would you mind providing the value you used for LLDB_SERVER_LOG_CHANNELS?

 

Demi

 

On Fri, Jul 21, 2017 at 2:55 PM Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

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 variables:
LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will
be written to
LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn
logging on for. The format is "channel category:channel category...". If you
want more than 1 category for a channel, I think "channel cat1 cat2..."
works. This is not spelled out very clearly, unfortunately.


Quickly glancing at the code, it looks like you need to implement a
socketpair connection, and handling of the fd:// connection URL, starting in
ConnectionFileDescriptor::Connect. The log for this would be "lldb
connection".

Ted

--
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 Demi
> Obenour via lldb-dev
> Sent: Wednesday, July 19, 2017 7:44 PM
> To: lldb-dev@lists.llvm.org  
> Subject: [lldb-dev] Trying to use socketpair for lldb-server fails
>
> To avoid a local privilage escalation, I am trying to patch LLDB not to
use a TCP
> socket for local communication.
>
> The attached patch failed.  Would anyone be able to provide suggestions
for
> how to debug the problem?
>
> Sincerely,
>
> Demi

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

Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

[Ted Woodward via lldb-dev]

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 Bugzilla at http://bugs.llvm.org .

Ted

--
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 Hafiz
> Abid Qadeer via lldb-dev
> Sent: Monday, July 31, 2017 5:04 AM
> To: Eli Zaretskii ; Zachary Turner ; Jan
> Kratochvil ; Eli Zaretskii via lldb-dev  d...@lists.llvm.org>
> Cc: yllumin...@gmail.com
> Subject: Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
> 
> 
> >>> Last time I tried, it wasn't "reasonable" enough to start debugging
> >> a
> >>> program under Emacs.  See this discussion for details:
> >>>
> >>> http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html
> >>>
> >>> The failed commands it shows are the initial ones issued by Emacs
> >>> when a debugging session starts.  Without support of these commands
> >> in
> >>> lldb-mi there's no hope for any
> >>> practical debugging using lldb.
> >>> If llvm developers could implement those minimal commands, maybe
> the
> >>> rest would be easier.
> 
> I will try to add those command when my time allows. If there are others that
> are needed to make Emacs work then please let me know or better open a
> bug.
> 
> Thanks,
> Abid
> 
> --
> Hafiz Abid Qadeer
> Mentor Embedded/CodeSourcery
> ___
> 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] Forcing lldb to refresh process state

[Ted Woodward via lldb-dev]

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, 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 Greg
Clayton via lldb-dev
Sent: Tuesday, August 22, 2017 6:20 PM
To: Vadim Chugunov 
Cc: LLDB 
Subject: Re: [lldb-dev] Forcing lldb to refresh process state

 

You need to send some sort of continue through the GDB remote interface. The
only way to get a $T packet back is in response to a "?" packet or to a
"vCont" or other continue or step packet.

 

On Aug 22, 2017, at 2:30 PM, Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

 

It does send '$T05...' in response, but it looks like lldb does not analyze
responses to manually sent packets.

 

On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton mailto:clayb...@gmail.com> > wrote:

If you do a reverse step it actually should send a process resumed and a
process stopped event.

> On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev mailto:lldb-dev@lists.llvm.org> > wrote:
>
> I'm trying to reverse-step.  So I think I'd need to refresh all thread
states?
>
>> On Aug 18, 2017, at 4:50 PM, Jim Ingham mailto:jing...@apple.com> > wrote:
>>
>> No, there hasn't been a need for this.
>>
>> What commands are you planning to send?  Or equivalently, how much state
are you expecting to change?
>>
>> Jim
>>
>>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
>>>
>>> Hi,
>>> Is there any way to force lldb to refresh it's internal record of
debuggee process state (as if it had just received a stop event)?  I want to
send a custom command to remote gdb process stub (via `process plugin packet
send`).  This works, but if the command alters debuggee state, lldb won't
know about it.
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org  
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org  
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 

 

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

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ted Woodward via lldb-dev]

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. StartDebugServerProcess 
launches the gdbserver with a named pipe, and reads the actual port from the 
pipe.

I suggest turning on more logging - specifically, "gdb-remote process". That's 
the channel used in StartDebugServerProcess.

--
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: Wednesday, August 23, 2017 12:45 PM
> To: Hans Wennborg 
> Cc: Ramana ; LLDB Dev  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Port zero should never be returned as a valid port. We do bind to port zero 
> just
> so we don't try and pick a port at random just to find it is being used. When 
> we
> bind to 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 function
> GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) in
> GDBRemoteCommunicationServerPlatform.cpp and see what is going on and
> why it is returning 0 as the port.
> 
> Greg
> 
> > On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > This was marked as an lldb 5.0.0 release blocker since it's a
> > regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183
> >
> > lldb-dev: Is there any interest in fixing this bug?
> >
> > On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
> >  wrote:
> >> 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 specification: '10.10.2.3'
> >>
> >> It appears the above error is because the gdb-remote is returning the
> >> communication port as zero.
> >>
> >> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
> >> <  19> read packet: $pid:298;port:0;#bf
> >>
> >> What are the possible reasons for the above behavior from gdb-remote
> >> and how I could resolve this?
> >>
> >> If it helps, below is the full log.
> >>
> >> (lldb) log enable lldb comm
> >> (lldb) log enable gdb-remote packets
> >> (lldb) platform select remote-linux
> >>  Platform: remote-linux
> >> Connected: no
> >> (lldb) platform connect connect://10.10.2.3:500
> >> 0x915bd78 Communication::Communication (name = gdb-remote.client)
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
> >> Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect
> >> (host/port = 10.10.2.3:500)
> >> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
> >> us, connection = 0x0915F578
> >> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
> >> flags = 0) => 19 (error = (null))
> >> history[1] tid=0x7cbf <   1> send packet: +
> >> <  19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst =
> >> 0xBFCB51AC, dst_len = 8192, timeout = 600 us, connection =
> >> 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
> >> flags = 0) => 7 (error = (null))
> >> <   1> read packet: +
> >> <   6> read packet: $OK#9a
> >> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
> >> flags = 0) => 13 (error = (null)) <  13> send packet: $qHostInfo#9b
> >> this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout =
> >> 100 us, connection = 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len =
> >> 316, flags = 0) => 316 (error = (null)) < 316> read packet:
> >>
> $triple:61726d2d2d6c696e75782d676e7565

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ted Woodward via lldb-dev]

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 debugserver launch, and get:

> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port

That log message comes right after the pipe read, which succeeds because 
error.Success() is true:

// Read port from pipe with 10 second timeout.
error = socket_pipe.ReadWithTimeout(
port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
if (error.Success() && (port != nullptr)) {
  assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
  uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
  if (*port == 0 || *port == child_port) {
*port = child_port;
if (log)
  log->Printf("GDBRemoteCommunication::%s() "
  "debugserver listens %u port",
  __FUNCTION__, *port);

As an aside, I don't like that assert - if we get garbage back from the pipe, 
we should error out, not take down lldb.

Another aside, the definition of port_cstr is odd:
char port_cstr[PATH_MAX] = {0};
port_cstr[0] = '\0';
The size is way to big - max port number is 65535, so we don't need PATH_MAX 
bytes. And 2 assignments to make it a null string?


Ramana, can you stick in a log message to print port_cstr? I suspect it's 
actually getting 0 back from lldb-server, which would tell us the error is in 
the server code, not the client code.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Ramana [mailto:ramana.venka...@gmail.com]
> Sent: Thursday, August 24, 2017 4:00 AM
> To: Ted Woodward 
> Cc: Greg Clayton ; Hans Wennborg
> ; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Greg, Ted
> 
> Thanks for your comments.
> 
> On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward
>  wrote:
> >
> > 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. StartDebugServerProcess
> launches the gdbserver with a named pipe, and reads the actual port from the
> pipe.
> 
> Yes, the port list is empty unless --(min/max)-gdbserver-port is specified and
> the gdbserver reads port number from the named pipe which in the failing case
> is zero.
> 
> > I suggest turning on more logging - specifically, "gdb-remote process". 
> > That's
> the channel used in StartDebugServerProcess.
> >
> 
> In fact I have given the relevant log line of "gdb-remote process" in the bug
> details reporting port zero. Anyhow, the full log of "gdb-remote process" for
> both lldb v4.0.1 and v5.0.0 is given at the bottom of my reply.
> 
> I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits for 
> child
> debug servers to start up when passing them) got something to do with this bug
> but both reversing
> 
> if (pass_comm_fd == -1) {   at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086
> 
> to original
> 
>if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port ==
> nullptr)) {
> 
> and
> 
> increasing the time out to 30 sec from 10 sec in
> socket_pipe.ReadWithTimeout()at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255
> 
> did not solve the issue.
> 
> By the way, the remote debugging of x86 (linux) from x86 (linux) with lldb
> v5.0.0 (but works with v4.0.1) also fails with assertion
> 
> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');  at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1258
> 
> due to the reason that socket_pipe.ReadWithTimeout() could not successfully
> read the port number from the named pipe.
> 
> Based on the above, though I am not sure, the other patch I could think of
> having an effect on this bug is
> https://reviews.llvm.org/rL300579 (Update LLDB Host to support IPv6 over TCP)
> which changed the socket implementation.
> 
> 
> lldb-server log for "gdb-remote process" with lldb v4.0.1 (passing case)
> 
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0,
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote stub
> exe '/mnt/var/binaries/arm_release/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server"
> argv[1]="gdbserver"
> argv[2]="tcp://10.10.12.3:0"
> argv[3]="--native-regs"
> argv[4]="--pipe"
> argv[5]="7"
> argv[6]=NU

[lldb-dev] hang bug in lldb-mi -var-update

[Ted Woodward via lldb-dev]

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_update_test(void)
{
struct complex_type complx_array[2];

complx_array[0].i = 4;
complx_array[0].inner.l = 4;
complx_array[0].complex_ptr = &complx_array[1];
complx_array[1].i = 5;
complx_array[1].inner.l = 5;
complx_array[1].complex_ptr = &complx_array[0];
 


the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
infinite loop.

  const MIuint nChildren = vrwValue.GetNumChildren();
  for (MIuint i = 0; i < nChildren; ++i) {
lldb::SBValue member = vrwValue.GetChildAtIndex(i);
if (!member.IsValid())
  continue;

if (member.GetValueDidChange()) {
  vrwbChanged = true;
  return MIstatus::success;
} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
  // Handle composite types (i.e. struct or arrays)
  return MIstatus::success;
  }

I've got a patch that disables checking a pointer's children. I'll put it up
on phabricator today.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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