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 mai
Yeah that would be awesome, and also would be a lot of work. Good luck!
On Fri, Nov 20, 2015 at 10:37 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> 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 Cla
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
differen
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
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 pyt
On Fri, Nov 20, 2015 at 10:05 AM Aidan Dodds wrote:
> 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
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 fin
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 (
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
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
>
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
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 whe
12 matches
Mail list logo
