[lldb-dev] LLDB expressions confused by overloading

[Aidan Dodds via lldb-dev]

I believe I have tracked down an interesting bug which related to LLDBs 
expression parser.


In my target program I have a math library, a shared object which makes 
use of clangs __attribute__((overloadable)) extension for C99.  This 
causes the the function names in the math library to be mangled.
A problem arises however since some of the function names mirror those 
exported by libm.so, and the function names in libm are not mangled.


My problem scenario:
If I call an expression during a debugging session, the symbol table of 
libm.so is consulted first and a match will be found.  Later on in the 
expression setup, any dwarf information will be consulted for functions 
with this name.  libm.so doesn't have any debugging info attached, 
however the math library of my target may.  In this case the expression 
will now call which ever function it could first find dwarf info for, 
regardless of the name mangling.


The net result is that a function will be called in my targets math 
library that may not match the given function signature.  In my case 
this causes the expression to raise a SEGFAULT and fail.  I was seeing 
an expression to call a vector4 function, in fact call the vector 2 
version behinds the scenes.


One solution to this problem seems to be to have the expression 
evaluator try and first look for any functions that may have a mangled 
name for the given function signature, and if that fails fall back to 
simply checking for the unmangled version, as is currently done.


Would this make sense?

It seems less then ideal to have a clash of mangled and unmangled names, 
but I can imagine this situation may not be all that rare.


I am happy to provide more info if it would be usefull.

Thanks,
Aidan

--
Aidan Dodds
staff software engineer, Debuggers
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St.
Edinbrgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged 
information and is for use by the addressee only. If you are not the intended 
recipient, please notify Codeplay Software Ltd immediately and delete the 
message from your computer. You may not copy or forward it,or use or disclose 
its contents to any other person. Any views or other information in this 
message which do not relate to our business are not authorized by Codeplay 
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd 
does not accept any responsibility for any changes made to this message after 
it was sent. Please note that Codeplay Software Ltd does not accept any 
liability or responsibility for viruses and it is your responsibility to scan 
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

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

Re: [lldb-dev] LLDB expressions confused by overloading

[Aidan Dodds via lldb-dev]

Thanks Siva,
This indeed looks somewhat related to the problems we are seeing here.
I'm just having a read of your patch now and going to try it out here.

On 05/11/2015 18:24, Siva Chandra wrote:

On Thu, Nov 5, 2015 at 9:43 AM, Aidan Dodds via lldb-dev
 wrote:

I believe I have tracked down an interesting bug which related to LLDBs
expression parser.

In my target program I have a math library, a shared object which makes use
of clangs __attribute__((overloadable)) extension for C99.  This causes the
the function names in the math library to be mangled.
A problem arises however since some of the function names mirror those
exported by libm.so, and the function names in libm are not mangled.

My problem scenario:
If I call an expression during a debugging session, the symbol table of
libm.so is consulted first and a match will be found.  Later on in the
expression setup, any dwarf information will be consulted for functions with
this name.  libm.so doesn't have any debugging info attached, however the
math library of my target may.  In this case the expression will now call
which ever function it could first find dwarf info for, regardless of the
name mangling.

The net result is that a function will be called in my targets math library
that may not match the given function signature.  In my case this causes the
expression to raise a SEGFAULT and fail.  I was seeing an expression to call
a vector4 function, in fact call the vector 2 version behinds the scenes.

One solution to this problem seems to be to have the expression evaluator
try and first look for any functions that may have a mangled name for the
given function signature, and if that fails fall back to simply checking for
the unmangled version, as is currently done.

Is this similar to the problem tackled by this patch:
http://reviews.llvm.org/D12809


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

Re: [lldb-dev] LLDB expressions confused by overloading

[Aidan Dodds via lldb-dev]

Hi Greg,

It turns out that the problem I was having was fixed when I patched a 
bug in DwarfSymbolFile:

http://reviews.llvm.org/D14538

But thanks for the additional info.

Aidan


On 12/11/2015 17:54, Greg Clayton wrote:

On Nov 5, 2015, at 9:43 AM, Aidan Dodds via lldb-dev  
wrote:

I believe I have tracked down an interesting bug which related to LLDBs 
expression parser.

In my target program I have a math library, a shared object which makes use of 
clangs __attribute__((overloadable)) extension for C99.  This causes the the 
function names in the math library to be mangled.
A problem arises however since some of the function names mirror those exported 
by libm.so, and the function names in libm are not mangled.

My problem scenario:
If I call an expression during a debugging session, the symbol table of libm.so 
is consulted first and a match will be found.  Later on in the expression 
setup, any dwarf information will be consulted for functions with this name.  
libm.so doesn't have any debugging info attached, however the math library of 
my target may.  In this case the expression will now call which ever function 
it could first find dwarf info for, regardless of the name mangling.

The net result is that a function will be called in my targets math library 
that may not match the given function signature.  In my case this causes the 
expression to raise a SEGFAULT and fail.  I was seeing an expression to call a 
vector4 function, in fact call the vector 2 version behinds the scenes.

One solution to this problem seems to be to have the expression evaluator try 
and first look for any functions that may have a mangled name for the given 
function signature, and if that fails fall back to simply checking for the 
unmangled version, as is currently done.

Would this make sense?

It seems less then ideal to have a clash of mangled and unmangled names, but I 
can imagine this situation may not be all that rare.

The correct fix for this is to have the DWARFASTParserClang, when it parses the 
function prototype, recognize that a C function (check the language of the 
compile unit) has a mangled name and enable the corresponding bit in the 
clang::FunctionType so that the expression parser knows to look for the mangled 
name when someone uses it. Then no changes to the expression parser should be 
required.

Greg Clayton



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

Re: [lldb-dev] LLDB Windows Python Bindings

[Aidan Dodds via lldb-dev]

First off thanks for opening that up to the mailing list, it will be 
good if discussion of this is useful to others.


From the python 3.5 case:
I'm not using ninja.build, but instead just compiling from the visual 
studio ide.  However, the custom build step I think you were referring 
to for finish_swig seems to be:


setlocal
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E copy 
C:\Python35\python35.dll D:\rs_project\rs_llvm_build\$(Configuration)\bin

if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd


The exact error message for building finish_swig was the following:

-- Build started: Project: finish_swig, Configuration: Debug x64 --
Build started 20/11/2015 17:27:07.
InitializeBuildStatus:
  Touching "x64\Debug\finish_swig\finish_swig.tlog\unsuccessfulbuild".
CustomBuild:
  Python script sym-linking LLDB Python API
  Traceback (most recent call last):
File 
"D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py", 
line 383, in 

  main(sys.argv[1:])
File 
"D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py", 
line 326, in main
  nResult, strMsg = 
run_post_process_for_each_script_supported(dictArgs)
File 
"D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py", 
line 281, in run_post_process_for_each_script_supported

  vDictArgs)
File 
"D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py", 
line 223, in run_post_process

  module = __import__(strModuleName)
File 
"d:\rs_project\rs_llvm\tools\lldb\scripts\python\finishSwigPythonLLDB.py", 
line 42, in 

  import ctypes   # Invoke Windows API for creating symlinks
File "C:\Python35\lib\ctypes\__init__.py", line 7, in 
  from _ctypes import Union, Structure, Array
  ImportError: No module named '_ctypes'


For the python 2.7 case:

The error I see in CMake is the following:

-- Found Python version 2.7.10+

Unable to find C:/Python27/libs/python27+_d.lib

Unable to find C:/Python27/libs/python27+.lib

Unable to find C:/Python27/python27+_d.dll

Unable to find C:/Python27/python27+.dll

Python installation is corrupt. Python support will be disabled for this 
build.



I'm not sure where the + comes from however...

Aidan@AIDAN-PC /c/Python27
$ python --version
Python 2.7.10

Aidan@AIDAN-PC /c/Python27
$ python_d --version
Python 2.7.10

As for the CMake options its again complicated because I'm using cmake-gui.
Hopefully the relevant params are:

PYTHON_EXCUTABLE = c:/python27/python_d.exe
PYTHON_HOME = c:/python27
LLDB_DISABLE_PYTHON = False
LLDB_RELOCATABLE_PYTHON = False
SWIG_DIR = d:/swig/lib
SWIG_EXECUTABLE = d:/swig/swig.exe
SWIG_VERSION = 3.0.5


I am using Visual Studio 2013 and doing an x86_64 build.
I compiled the python interpreter with the same version also.

Its not a requirement for me to custom python for any reason, I just 
remember there being issues with using the release package.


Thanks,
Aidan

On 19/11/2015 18:01, Zachary Turner wrote:

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


Hi Zachary,

I am currently trying to produce a win

Re: [lldb-dev] LLDB build at windows

[Aidan Dodds via lldb-dev]

Just to chip in on this thread.
I regularly build X64 LLDB using Visual Studio, but I only use it for 
debugging remote targets.
I have noticed the gtests linking error, but unfortunately due to tight 
time constraints I've not been free to fix it.
I tend to 'unload' all of the projects in Visual Studio that are not 
directly related to building LLDB, so I don't see the linking error 
often.  Also since its not a direct dependency, LLDB still builds fine 
for me.


Fixes are always nice however :)

Last I checked I was able to build LLDB in VS2013 as well as VS2015 
without problems.


On 11/01/2016 18:48, Zachary Turner via lldb-dev wrote:
Yea, unfortunately the way things work is that the person who is 
affected by the problem and who needs it fixed is usually the one that 
needs to fix it.  Right now we don't have any Windows people building 
inside Visual Studio, so nobody has fixed that.  But you're welcome to 
submit a patch :)


FWIW, I actually generate CMake twice, into two separate folders.  I 
have build/vs and build/ninja.  In the vs directory I generate using 
"Visual Studio 14 2015" generator, and in ninja I generate using Ninja 
generator.  I build from the Ninja folder, and I use the vs folder 
just for opening a solution, source browsing, and debugging (i.e. 
change the Debugger settings to point the executable into the ninja 
folder).


This way you still do everything from vs, just not the compile step.

On Mon, Jan 11, 2016 at 9:16 AM Red Skotina > wrote:


thanks. i build successefuly llvm and lldb with ninja and cl
compiler.

If i build VS solution without options on CMake then i have ever
more errors around unittests in llvm.

like that:

"d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
"d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj"
(целевой объект по
 умолчанию) (749) ->
"d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой
объект по умолчани
ю) (750) ->
(Целевой объект ClCompile) ->
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
C2327: 'll
vm::PointerEmbeddedInt::Value': is not a type name,
static, or enume
rator (compiling source file
D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt
Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
C2065: 'Va
lue': undeclared identifier (compiling source file
D:\code\llvm\llvm\unittests\
ADT\PointerEmbeddedIntTest.cpp)
[d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
roj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
C2327: 'll
vm::PointerEmbeddedInt::Value': is not a type name, static,
or enumerato
r (compiling source file
D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error
C2338: Can
not embed more bits than we have in a pointer! (compiling source
file D:\code\l
lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp)
[d:\code\llvm\build\unittest
s\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
C2327: 'll
vm::PointerEmbeddedInt::Value': is not a type name, static,
or enumerato
r (compiling source file
D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
C2065: 'Va
lue': undeclared identifier (compiling source file
D:\code\llvm\llvm\unittests\
ADT\PointerEmbeddedIntTest.cpp)
[d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
roj]

2016-01-11 0:56 GMT+03:00 Zachary Turner mailto:ztur...@google.com>>:

I have never built with -DLLVM_INCLUDE_TESTS=OFF
-DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before,
so that could be related.  Can you try removing those options
on CMake to see if that fixes it?

The other thing I do differently is I use ninja generator.  So
I use -G Ninja instead of -G "Visual Studio 14 2015". 
Building from within Visual Studio like you're doing is

supposed to work, I just don't know if anyone tests it.  My
command line is usually:

cmake -G Ninja  -DCMAKE_BUILD_TYPE=Release
-DPYTHON_HOME=
..\llvm

ninja


On Sun, Jan 10, 2016 at 4:02 AM Red Skotina
mailto:red.skot...@gmail.com>> wrote:

thanks.
i still have 5 errors while linking
"d:\code\llvm\build\LLVM.sln" (целевой объект по
умолчанию) (1) ->

"d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj"
(целев
ой объект по умолчанию) (741) ->

"d:\cod

[lldb-dev] LLDB windows build and /bigobj

[Aidan Dodds via lldb-dev]

Hi all,

I pulled in recent changes to upstream llvm, clang and lldb and it seems
to have tipped my windows build over the edge, and its complaining that
my object files have exceeded the section limit.
This error is raised while building the clang libraries.  Has anyone
else seen this problem while doing an x64 build with with Visual Studio
2015?

This problem can be fixed however by specifying /bigobj as a compiler
flag.  The problem is however that this needs to be given to clang,
which in turn inherits most of its cmake from llvm.

I have attached my prospective patch for this issue, but wanted to check
in with the lldb folk first to see if anyone has hit this issue, and if
they would have any feedback before I submit it to llvm.

Thanks,
Aidan

--
Aidan Dodds
staff software engineer, Debuggers
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St.
Edinbrgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged 
information and is for use by the addressee only. If you are not the intended 
recipient, please notify Codeplay Software Ltd immediately and delete the 
message from your computer. You may not copy or forward it,or use or disclose 
its contents to any other person. Any views or other information in this 
message which do not relate to our business are not authorized by Codeplay 
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd 
does not accept any responsibility for any changes made to this message after 
it was sent. Please note that Codeplay Software Ltd does not accept any 
liability or responsibility for viruses and it is your responsibility to scan 
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY







diff --git a/cmake/modules/AddLLVM.cmake b/cmake/modules/AddLLVM.cmake
index d825c58..f097fc3 100644
--- a/cmake/modules/AddLLVM.cmake
+++ b/cmake/modules/AddLLVM.cmake
@@ -8,6 +8,12 @@ function(llvm_update_compile_flags name)
 set(update_src_props ON)
   endif()
 
+  # Visual Studio 2015 builds can hit the object file format section limit.
+  # Building with the /bigobj flag lifts this size restriction.
+  if(MSVC14)
+list(APPEND LLVM_COMPILE_FLAGS "/bigobj")
+  endif()
+
   # LLVM_REQUIRES_EH is an internal flag that individual
   # targets can use to force EH
   if((LLVM_REQUIRES_EH OR LLVM_ENABLE_EH) AND NOT CLANG_CL)


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

Re: [lldb-dev] LLDB windows build and /bigobj

[Aidan Dodds via lldb-dev]

Hi Reid,
Thanks for taking a look at this.
Here was the full error:

llvm\tools\clang\lib\ASTMatchers\Dynamic\Registry.cpp : fatal error C1128: 
number of sections exceeded object file format limit: compile with /bigobj

That file seems to have quite a bit of macro magic going on, so I'll try 
to dig deeper into this when I'm back in the office tomorrow.


On 09/02/2016 17:11, Reid Kleckner wrote:
Which object file has crossed the limit? When this has happened 
before, this has usually highlighted over use of templates, which is 
worth fixing because it speeds up builds on other platforms as well. 
If MSVC 2015 instead just happens to generate say one extra section 
per function, then we should probably use bigobj.


On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:


Hi all,

I pulled in recent changes to upstream llvm, clang and lldb and it
seems
to have tipped my windows build over the edge, and its complaining
that
my object files have exceeded the section limit.
This error is raised while building the clang libraries. Has anyone
else seen this problem while doing an x64 build with with Visual
Studio
2015?

This problem can be fixed however by specifying /bigobj as a compiler
flag.  The problem is however that this needs to be given to clang,
which in turn inherits most of its cmake from llvm.

I have attached my prospective patch for this issue, but wanted to
check
in with the lldb folk first to see if anyone has hit this issue,
and if
they would have any feedback before I submit it to llvm.

Thanks,
Aidan

-- 
Aidan Dodds

staff software engineer, Debuggers
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St.
Edinbrgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or
privileged information and is for use by the addressee only. If
you are not the intended recipient, please notify Codeplay
Software Ltd immediately and delete the message from your
computer. You may not copy or forward it,or use or disclose its
contents to any other person. Any views or other information in
this message which do not relate to our business are not
authorized by Codeplay software Ltd, nor does this message form
part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay
Software Ltd does not accept any responsibility for any changes
made to this message after it was sent. Please note that Codeplay
Software Ltd does not accept any liability or responsibility for
viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY








___
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] Inquiry about LLDB remote protocol

[Aidan Dodds via lldb-dev]

The GDB RSP, which LLDB RSP is derived from is certainly state-full and 
maintains an notion of the current thread for queries (reading 
registers, etc..) and for execution commands (stepping), see the 'H' packet.
The RSP has evolved quite a bit however and extended packets were 
introduced that do take TID's as a parameter (vcont for instance).

Hopefully someone can chip in who is more familiar with lldb-server however.

As for your other question, the RSP should however be relatively 
platform independent as far as state-fullness goes, I don't think and of 
the upstream lldb platforms keep an kind of special state.


Disclaimer... Its been a little while since I have had to really dig 
into RSP so its all liable to have changed.



On 29/03/2016 10:57, Ravitheja Addepally via lldb-dev wrote:

Hello,
  I wanted to know if the remote protocol of LLDB is state less or 
not ? When i say state I am referring to if LLDB remembers the current 
process or thread being debugged (which would mean we dont need to 
specify that in the client to server packets ) . I was looking at the 
GDBRemoteCommunicationServerLLGS and found that most of the packets 
did not have the pid or thread id being passed to the server , so is 
it safe to assume that the protocol is statefull ? is this assumption 
also valid for all OS's ?


---Ravi


___
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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Aidan Dodds via lldb-dev]

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  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]
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  
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; LL

[lldb-dev] Where should PROLOGUE_END be set

[Aidan Dodds via lldb-dev]

Hello all,

It seems that different LLVM backends (ARM, MIPS, X86) can output a 
different line number for PROLOGUE_END in the DWARF line table.


Say I have a function as follows:

1. int my_function( int arg1 )
2. {
3.some_code();
4.

At -O0 I am seeing the PROLOGUE_END set on the function definition (1.,
ARM) and on the first line of code (3., X86, MIPS)
At -03 the ARM backend uses line 3 as its PROLOGUE_END.

Is there a 'correct' place for this to be set, or is expected that this 
can be different?
If it is somehow language defined then I am most interested in an answer 
related to C99.


Thanks,
Aidan

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

Re: [lldb-dev] Where should PROLOGUE_END be set

[Aidan Dodds via lldb-dev]

Ok that clears things up for me.
Thanks Greg.

Aidan

On 31/08/2015 20:50, Greg Clayton wrote:

It is just defined to be where all of the prologue instructions are done 
setting up the stack frame for the current function. There is no right answer 
in terms of source lines, the compiler can say anything it wants to.

Greg


On Aug 31, 2015, at 4:22 AM, Aidan Dodds via lldb-dev  
wrote:

Hello all,

It seems that different LLVM backends (ARM, MIPS, X86) can output a different 
line number for PROLOGUE_END in the DWARF line table.

Say I have a function as follows:

1. int my_function( int arg1 )
2. {
3.some_code();
4.

At -O0 I am seeing the PROLOGUE_END set on the function definition (1.,
ARM) and on the first line of code (3., X86, MIPS)
At -03 the ARM backend uses line 3 as its PROLOGUE_END.

Is there a 'correct' place for this to be set, or is expected that this can be 
different?
If it is somehow language defined then I am most interested in an answer 
related to C99.

Thanks,
Aidan

___
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