https://llvm.org/bugs/show_bug.cgi?id=25081
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://llvm.org/bugs/show_bug.cgi?id=25086
Bug ID: 25086
Summary: lldb should use unix socket for communication with
server on linux
Product: lldb
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
https://llvm.org/bugs/show_bug.cgi?id=25087
Bug ID: 25087
Summary: Stripped symbol handling when using dwo sdebug info
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
https://llvm.org/bugs/show_bug.cgi?id=25086
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://llvm.org/bugs/show_bug.cgi?id=25086
Zeljko Vrba changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://llvm.org/bugs/show_bug.cgi?id=25092
Bug ID: 25092
Summary: Test suit is flaky if 2 tests have the same file name
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: norm
We should explicitly disallow it. You should be able to tell by looking at
a test's filename what it does. If two files have the same name, then you
wonder why they aren't the same test, and it leaves you with more questions
than answers. If two tests have the same name and they actually *should
https://llvm.org/bugs/show_bug.cgi?id=25097
Bug ID: 25097
Summary: LLDB Unit Tests cannot find the shared library
directory
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status:
Jim, Greg,
Can I get some feedback on this? I would like to start enforcing this
moving forward. I want to make sure we're in agreement.
On Mon, Oct 5, 2015 at 12:30 PM Todd Fiala wrote:
> IMHO that all sounds reasonable.
>
> FWIW - I wrote some tests for the test system changes I put in (for
> On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev
> wrote:
>
> Jim, Greg,
>
> Can I get some feedback on this? I would like to start enforcing this moving
> forward. I want to make sure we're in agreement.
>
> On Mon, Oct 5, 2015 at 12:30 PM Todd Fiala wrote:
> IMHO that all sou
Hello,
I am trying to see what is going inside LLDB server 3.7.0 but there are a lot
of timeouts scattered everywhere. Say, InferiorCallPOSIX.cpp:74 sets hard-coded
timeout to 500,000us, etc. These timeouts fire if I spend any time on
breakpoint inside server and make debugging experience mise
On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote:
>
>
> > On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Jim, Greg,
> >
> > Can I get some feedback on this? I would like to start enforcing this
> moving forward. I want to make sure we're i
On Wed, Oct 7, 2015 at 10:37 AM Zachary Turner wrote:
> One more question: I mentioned earlier that we should enforce the
> distinction between HandleCommand tests and python api tests at an
> organizational level. In other words, all HandleCommand tests go in
> lldb/test/command-api, and all ne
Most calls for lldb-server should use an instance variable
GDBRemoteCommunication::m_packet_timeout which you could then modify. But this
timeout you are talking about is the time that the expression can take when
running. I would just bump these up temporarily while you are debugging to
avoid
Thanks!
A newbie question then: how to trigger LLDB_CONFIGURATION_DEBUG when I run
cmake? I am sure that I built debug version, but packet timeout is still 1 to
me.
(gdb) p m_packet_timeout
$1 = 1
> Subject: Re: [lldb-dev] How to debug LLDB server?
> From: gclay...@apple.com
> Date: Wed,
>
> So in summary, it sounds like we agree on the following guidelines:
>
> 1) If you're committing a CL and it is possible to test it through the SB
> API, you should only submit an SB API test, and not a HandleCommand test.
agreed
> 2) If you're committing a CL and it's not possible to test
> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev
> wrote:
>
>
>
> On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote:
>
>
> > On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev
> > wrote:
> >
> > Jim, Greg,
> >
> > Can I get some feedback on this? I would like to start e
> On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote:
>
>>
>> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev
>> wrote:
>>
>>
>>
>> On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote:
>>
>>
>>> On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev
>>> wrote:
>>>
>>> Jim, Greg,
On Wed, Oct 7, 2015 at 11:26 AM Jim Ingham wrote:
>
> > On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote:
> >
> >>
> >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >>
> >>
> >> On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton
> wrote:
> >>
> >>
>
> On Oct 7, 2015, at 11:40 AM, Zachary Turner wrote:
>
>
>
> On Wed, Oct 7, 2015 at 11:26 AM Jim Ingham wrote:
>
> > On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote:
> >
> >>
> >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev
> >> wrote:
> >>
> >>
> >>
> >> On Wed, Oct 7, 2015 at
Hi,
I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint and if
I call SBFrame::EvaluateExpression() there, when I let it go it terminates with
SIG_ILL on an innocent thread. I dug up into this, and there seems to be two
independent problems there, this mail is about the sec
Hi Zachary,
Ok so I did end up reconfiguring it and rebuilding but that was no help
. I then realized that I was importing python27.dll as well as
python27_d.dll . When I rebuilt liblldb I started getting an single
unresolved error for
imp_Py_InitModule which I guess was the symbol for the Py_
What are the chances of someone attempting to get the existing unit test
runner working in the Xcode build? Or at least attempting to and seeing if
there's any major blockers that prevent it from working?
On Wed, Oct 7, 2015 at 11:54 AM Jim Ingham wrote:
>
> > On Oct 7, 2015, at 11:40 AM, Zacha
When you built LLDB, did you specify a -DPYTHON_HOME= on your CMake
command line, and also run the install_custom_python.py script? There's a
lot of steps, so it seems like almost everybody misses at least one step
when doing this.
I'm actively working (as in, literally right now) on getting LLDB
We set this manually in the Xcode project for "Debug" and "DebugClang" build
variants. The cmake should be able to do the same, but I am not sure if it is.
Feel free to make it do so. I am not very good with cmake, so I won't be much
help.
Greg
> On Oct 7, 2015, at 11:09 AM, Eugene Birukov wr
Hey Zachary,
> What are the chances of someone attempting to get the existing unit test
runner working in the Xcode build? Or at least attempting to and seeing if
there's any major blockers that prevent it from working?
I fully intend to do that. I need to do a few more pieces of
infrastructura
I'll work my way backwards . Eventually I'll get there. Anyway if you
need any help on adding python 3 support , I'll be more than happy to help
thanks ,
Que
On 07/10/15 20:40, Zachary Turner wrote:
When you built LLDB, did you specify a -DPYTHON_HOME= on your
CMake command line, and also run
I'm about 90% of the way there on the native code side. The last part is
tricky, but still mechanical. After I finish that the trick is going to be
getting the test suite running. I suspect that will be nasty, just because
there's a few thousand lines of code and it's going to be a pain to find
Does it only happen for InferiorCallMmap, or does an expression evaluation that
crashes in general set a bad signal on resume? I don't see this behavior in
either case on OS X, so it may be something in the Linux support. Be
interesting to figure out why it behaves this way on Linux, so whatev
Adding a printing destructor to threading.Event seems to aggravate timing
problems, causing several tests to fail to make their inferiors and that
seemingly keeps us below the open file limit. That aside, the destructor
did fire many hundreds of times, so there's not a general problem stopping
all
Zach had the clue that found the problem. Python on Windows uses the stdio
from CRT. On Windows, the default limit for open file descriptors is 512.
When you have 40 logical cores and the parent process spends several FDs
communicating with each one, you get real close to that number.
https://ms
Even on Linux call to InferiorCallMmap does not fail consistently. In many
cases it survives. I just happened to have 100% repro on this specific
breakpoint in my specific problem. I.e. the burden of investigation is on me,
since I cannot share my program.
But I am not looking at this SIG_ILL y
> On Oct 7, 2015, at 4:06 PM, Eugene Birukov wrote:
>
> Even on Linux call to InferiorCallMmap does not fail consistently. In many
> cases it survives. I just happened to have 100% repro on this specific
> breakpoint in my specific problem. I.e. the burden of investigation is on me,
> since I
On Mon, Oct 05, 2015 at 03:01:28PM -0700, Jim Ingham wrote:
>
> Given that, the best lldb can do is use heuristics, and the best heuristic I
> had was Block == basic block???
Can you at least check for branches then? (Yes, that would require
dissassebly).
> The motivation is that compilers
> On Oct 7, 2015, at 4:39 PM, d...@burble.org wrote:
>
> On Mon, Oct 05, 2015 at 03:01:28PM -0700, Jim Ingham wrote:
>>
>> Given that, the best lldb can do is use heuristics, and the best heuristic I
>> had was Block == basic block???
>
> Can you at least check for branches then? (Yes, that
In the LLDB project, you have 3 different defines:
LLDB_CONFIGURATION_DEBUG
LLDB_CONFIGURATION_RELEASE
LLDB_CONFIGURATION_BUILD_AND_INTEGRATION
I can easily set this up to be set for the various build types in cmake,
but I'd like to make sure we all agree about what should happen first:
CMAKE_BU
Hi,
I am writing a python script to set source line breakpoint in ObjC on Mac
OSX.
But
self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
line) always fail. Any ideas?
Also, can I use full path instead of file basename? In lldb, I found "b
/Users/jeffreytan/fbsourc
37 matches
Mail list logo
