Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on windows

[Tamas Berghammer via lldb-dev]

I don't know how JIT debugging should work on WIndows with MSVC but I don't
think LLDB support it in any way. What I wrote should be true on Linux (and
on some related) systems. You might be able to get the same results on
Windows if you use lli (LLVM based JIT runner) but I have no knowledge if
it will work or not.

On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:

> My analysis of the code, the reasons are:
>
> Since the debugging process is MSVC compiler, there is no DWARF debugging
> information. So lldb get __jit_debug_register_code and
> __it_debug_descriptor symbol debugging process fails, and
> __jit_debug_register_code not support MSVC.
> I do not know whether correct?
>
> -- original message--
> *From:*"Tamas Berghammer";tbergham...@google.com;
> Date*:*2015年11月19日 PM 8:37
> *receive:* " "; "lldb-dev";
>
> *Subject:* Re: [lldb-dev] lldb debug jit-compiled code with llvm on
> windows
>
> In theory you don't have to do anything special to debug some JIT-ed code
> as everything should just work (based on the gdb jit interface). In
> practice I tried it out a few days ago and it wasn't working at all even in
> the case when the application is launched under LLDB (not with attach).
> LLDB was understanding the eh_frame for the JIT-ed code but didn't found
> the debug info for unknown reason. We should investigate it and try to fix
> it sometime. We (lldb for android developers) plan to do it sometime but if
> you are interested in it then please feel free to take a look and let us
> know if you have any question.
>
> Tamas
>
> On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> hi,
>> process A generate function Func1 code with llvm jit compiler, and calls
>> Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
>> information. how to use LLDB to attach process A to debug this function, add
>> a breakpoint in the function?
>>
>> thanks!
>> ___
>> 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] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

[Ravitheja Addepally via lldb-dev]

Thanx, The invalid iterator problem was only in the last iteration, but I
think you modified all the For Loops.

On Fri, Nov 20, 2015 at 12:13 AM, Greg Clayton  wrote:

> I fixed this:
>
> % svn commit
> Sendinginclude/lldb/Symbol/TypeMap.h
> Sendingsource/Symbol/SymbolContext.cpp
> Sendingsource/Symbol/TypeMap.cpp
> Transmitting file data ...
> Committed revision 253618.
>
>
> > On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> >  Pavel- my question is how do we solve it ? should Mikhail log a bug
> ? for this issue
> >
> > BR,
> > A Ravi Theja
> >
> > On Tue, Nov 17, 2015 at 10:42 AM, Ravitheja Addepally <
> ravithejaw...@gmail.com> wrote:
> > Hello,
> >
> > Yeah you are right Mikhail, thanks for pointing it out,
> I must ask, is there any bug already logged for this issue ?
> >
> > Ravi
> >
> >
> > On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > Hi guys and thank you for the excellent community project!
> >
> >
> >
> > Recently I’ve stumbled on a pesky, but trivial Invalid iterator
> dereference bug in SymbolContext and TypeMap implementations at revisions
> >
> >
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
> >
> > and
> >
> >
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
> >
> >
> >
> > From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
> >
> >
> >
> > SymbolContext::SortTypeList(TypeMap _map, TypeList _list )
> const
> >
> > {
> >
> > TypeMaptoList callbackM2L (type_map, type_list);
> >
> > type_map.ForEach(callbackM2L);
> >
> > return ;
> >
> > }
> >
> >
> >
> > void
> >
> > TypeMap::ForEach (std::function  const
> )
> >
> > {
> >
> > for (auto pos = m_types.begin(), end = m_types.end(); pos != end;
> ++pos)
> >
> > {
> >
> > if (!callback(pos->second))
> >
> > break;
> >
> > }
> >
> > }
> >
> >
> >
> > bool
> >
> > TypeMap::RemoveTypeWithUID (user_id_t uid)
> >
> > {
> >
> > iterator pos = m_types.find(uid);
> >
> >
> >
> > if (pos != m_types.end())
> >
> > {
> >
> > m_types.erase(pos);
> >
> > return true;
> >
> > }
> >
> > return false;
> >
> > }
> >
> >
> >
> > class TypeMaptoList
> >
> > {
> >
> > public:
> >
> > TypeMaptoList(TypeMap , TypeList ) :
> >
> > type_map(typem),type_list(typel)
> >
> > {
> >
> > }
> >
> >
> >
> > bool
> >
> > operator() (const lldb::TypeSP& type)
> >
> > {
> >
> > if(type)
> >
> > {
> >
> > type_list.Insert(type);
> >
> > type_map.RemoveTypeWithUID(type->GetID());
> >
> > if (type_map.Empty())
> >
> > return false;
> >
> > }
> >
> > return true;
> >
> > }
> >
> >
> >
> > private:
> >
> > TypeMap _map;
> >
> > TypeList _list;
> >
> > };
> >
> >
> >
> > Regards,
> >
> > Mikhail Filimonov
> >
> >
> >
> >
> >
> >
> >
> > This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> >
> > ___
> > 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] reply： lldb debug jit-compiled code with llvm on windows

[Zachary Turner via lldb-dev]

Can you also try clang-cl and see if it works?

On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I don't know how JIT debugging should work on WIndows with MSVC but I
> don't think LLDB support it in any way. What I wrote should be true on
> Linux (and on some related) systems. You might be able to get the same
> results on Windows if you use lli (LLVM based JIT runner) but I have no
> knowledge if it will work or not.
>
> On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:
>
>> My analysis of the code, the reasons are:
>>
>> Since the debugging process is MSVC compiler, there is no DWARF debugging
>> information. So lldb get __jit_debug_register_code and
>> __it_debug_descriptor symbol debugging process fails, and
>> __jit_debug_register_code not support MSVC.
>> I do not know whether correct?
>>
>> -- original message--
>> *From:*"Tamas Berghammer";tbergham...@google.com;
>> Date*:*2015年11月19日 PM 8:37
>> *receive:* " "; "lldb-dev";
>>
>> *Subject:* Re: [lldb-dev] lldb debug jit-compiled code with llvm on
>> windows
>>
>> In theory you don't have to do anything special to debug some JIT-ed code
>> as everything should just work (based on the gdb jit interface). In
>> practice I tried it out a few days ago and it wasn't working at all even in
>> the case when the application is launched under LLDB (not with attach).
>> LLDB was understanding the eh_frame for the JIT-ed code but didn't found
>> the debug info for unknown reason. We should investigate it and try to fix
>> it sometime. We (lldb for android developers) plan to do it sometime but if
>> you are interested in it then please feel free to take a look and let us
>> know if you have any question.
>>
>> Tamas
>>
>> On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> hi,
>>> process A generate function Func1 code with llvm jit compiler, and calls
>>> Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
>>> information. how to use LLDB to attach process A to debug this function, add
>>> a breakpoint in the function?
>>>
>>> thanks!
>>> ___
>>> 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 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 

Re: [lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

Seems reasonable.  I will make a best effort to get as many of them as I
can.

On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton  wrote:

> Zach, I would also like to get rid of all global variables in the process
> of this change. The history goes like this: a long time ago someone wrote
> the initial dotest.py and parsed the options manually and stored results in
> global variables. Later, someone converted the options over to use a python
> library to parse the options, but we mostly copied the options from the
> options dictionary over into the globals and still use the globals all over
> the code. It would be great if we had at most one global variable that is
> something like "g_options" and anyone that was using any global variables
> will switch over to use the "g_options." instead. Then we don't have to
> make copies and we can let the g_options contain all settings that are
> required.
>
> > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I would like to do a complete audit of dotest's command line options,
> find out who's using what, and then potentially delete anything that isn't
> being used.  There's a mess of command line options in use, to the point
> that it's often hard to find free letters to use for new options.
> >
> > I created this spreadsheet with a complete list of command line options,
> their descriptions, and a place for people to enter what options they're
> using or do not want to be deleted.
> >
> >
> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> >
> > If someone has already written YES in the box that indicates they need
> the option, please don't overwrite it.  If you write YES in a box, please
> provide at least a small rationale for why this option is useful to you.
> Feel free to add additional rationale if someone has already added some
> rationale.
> >
> > I'm going to have a couple days in mid-December and do this cleanup, so
> I'd like to get a solid picture of what options are not needed before
> then.  After people have had some time to look over this, I'll go through
> the results and decide what to do with each one, and then send out another
> email with a proposed action column for each command line option.
> >
> > Please do take the time to have a look at this, because any option that
> doesn't have a YES in it after a couple of weeks I'm going to assume is a
> candidate for deletion.
> >
> >
> > ___
> > 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 with app using shared lib not working

[Greg Clayton via lldb-dev]

You can else set environment variables when you launch manually:

(lldb) process launch -v DYLD_FRAMEWORK_PATH=/tmp -- arg1 arg2

"env" is nice because it sets it permanently for your target and you don't have 
to specify it over and over. But it you ever want to _sometimes_ launch with a 
different framework, the "-v" or "--environemnt" option to process launch can 
come in handy.

Greg 

> On Nov 20, 2015, at 5:06 AM, Andre Alefeld via lldb-dev 
>  wrote:
> 
> FYI,
> 
> I found the solution to the problem:
> DYLD_* env variables are purged from the environment due to SIP in El Capitan.
> It is necessary to set any DYLD_* variable settings within (lldb)
> 
> e.g.
> lldb -f DARWIN_X64/test_app
> (lldb) target create "DARWIN_X64/test_app"
> Current executable set to 'DARWIN_X64/test_app' (x86_64).
> (lldb) env DYLD_LIBRARY_PATH=
> (lldb) r
> 
> then the shared lib is honored as expected inside lldb.
> 
>  
> 
>  Forwarded Message 
> Subject:  lldb with app using shared lib not working
> Date: Thu, 19 Nov 2015 13:24:46 +0100
> From: Andre Alefeld 
> To:   lldb-dev@lists.llvm.org
> 
> Hi,
> 
> if I try to debug an application from the terminal that is using a
> shared lib lldb complains always about not finding the library even
> though everything is loading correctly when starting the app directly
> from the same terminal:
> 
> echo $DYLD_LIBRARY_PATH/
> 
> 
> running with debugger, shared lib can be loaded:
> test_app
> 
> otool -L DARWIN_X64/test_app
> DARWIN_X64/test_app:
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1225.1.1)
> libmyapp.dylib (compatibility version 0.0.0, current version 0.0.0)
> 
> 
> 
> lldb -f DARWIN_X64/test_app
> (lldb) target create "DARWIN_X64/test_app"
> Current executable set to 'DARWIN_X64/test_app' (x86_64).
> (lldb) r
> Process 32234 launched: '/Users/xxx/yyy/zzz/source/DARWIN_X64/test_app'
> (x86_64)
> dyld: Library not loaded: libmyapp.dylib
>   Referenced from: /Users/xxx/yyy/zzz/source/DARWIN_X64/test_app
>   Reason: image not found
> Process 32234 stopped
> * thread #1: tid = 0x85c524, 0x7fff5fc01075 dyld`dyld_fatal_error +
> 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
> frame #0: 0x7fff5fc01075 dyld`dyld_fatal_error + 1
> dyld`dyld_fatal_error:
> ->  0x7fff5fc01075 <+1>: nop   
> 
> dyld`dyldbootstrap::start:
> 0x7fff5fc01076 <+0>: pushq  %rbp
> 0x7fff5fc01077 <+1>: movq   %rsp, %rbp
> 0x7fff5fc0107a <+4>: pushq  %r15
> 
> 
> how can I achieve that the shared lib is used in the debugger correctly,
> do I have to set some additional environment variables. Is there a
> special r (process launch) syntax that I need to use ?
> 
> in gdb it used to work like a charm...
> 
> thanks for any help you can deliver in advance,
> 
> Andre
> 
> 
> 
> 
> 
> ___
> 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] reply?? lldb debug jit-compiled code with llvm on windows

[haifeng_q via lldb-dev]

My analysis of the code, the reasons are:
  
  Since the debugging process is MSVC compiler, there is no DWARF debugging 
information. So lldb get __jit_debug_register_code and __it_debug_descriptor 
symbol debugging process fails, and __jit_debug_register_code not support MSVC.

 I do not know whether correct?
 

 -- original message--
  From:"Tamas Berghammer";tbergham...@google.com;
 Date:2015??11??19?? PM 8:37
 receive: " "; "lldb-dev"; 
 
 Subject: Re: [lldb-dev] lldb debug jit-compiled code with llvm on windows

 

 In theory you don't have to do anything special to debug some JIT-ed code as 
everything should just work (based on the gdb jit interface). In practice I 
tried it out a few days ago and it wasn't working at all even in the case when 
the application is launched under LLDB (not with attach). LLDB was 
understanding the eh_frame for the JIT-ed code but didn't found the debug info 
for unknown reason. We should investigate it and try to fix it sometime. We 
(lldb for android developers) plan to do it sometime but if you are interested 
in it then please feel free to take a look and let us know if you have any 
question.  

 Tamas


  On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev 
 wrote:

  hi,
 process A generate function Func1 code with llvm jit compiler, and calls 
Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug 
information. how to use LLDB to attach process A to debug this function, add a 
breakpoint in the function?
  
 thanks!
___
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] lldb-server/debugserver tests and debuginfo build type

[Todd Fiala via lldb-dev]

Hi all,

I think the vast majority of those likely aren't concerned with debug info
format.  Most of us are off next week, but when we get back I'll look into
getting those to run without debuginfo variants except where needed.

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