Since I am working on debugger support for OCaml, I am dealing with symbols of
the following form:
camlFoo__bar_1010
The function name is prefixed with the "caml" followed by the local module
name. OCaml is using a dot instead of a double colon to access function within
a module, and is replac
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 ma
+Eric Christopher
Adding Eric as he was the last person merging changes to the google/stable
branch. As far as I know nobody releases LLDB from that branch so I
wouldn't rely on it too much (Android Studio release from master) but you
can gave it a try if you want.
Tamas
On Fri, Apr 29, 2016 at
The code accessing another CU while indexing is in DWARFCompileUnit::GetDIE.
If the DIE is not in the current CU, it finds the CU that has it and calls its
::GetDIE method, accessing its m_die_array data...
So the question is: is it a producer (CU should be self-contained) or a
consumer (the in
Bumping this. If someone could point me to the build scripts used or some
documentation for how the nightly builds run, I can investigate the lldb
package issues on my own from there. Thanks!
Francis
On Wed, Apr 27, 2016 at 9:22 AM Francis Ricci
wrote:
> CC-ing llvm-dev.
>
> On Wed, Apr 27, 201
I didn't have any luck with r266423, these dwarf issues can get pretty
tricky.
Ok, that makes sense. We've been using these commits on top of our
release_38 branch for several weeks now, and I'm happy with their
stability. I'll continue to be on the lookout for bugs and bug-fixes.
Hans, can we ge
+Tom who owns the 3.8.1 release
On Tue, May 3, 2016 at 10:04 AM, Francis Ricci via lldb-dev
wrote:
> I didn't have any luck with r266423, these dwarf issues can get pretty
> tricky.
>
> Ok, that makes sense. We've been using these commits on top of our
> release_38 branch for several weeks now, a
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
> -Origina
> On May 3, 2016, at 6:35 AM, Philippe Lavoie
> wrote:
>
> The code accessing another CU while indexing is in DWARFCompileUnit::GetDIE.
> If the DIE is not in the current CU, it finds the CU that has it and calls
> its ::GetDIE method, accessing its m_die_array data...
>
> So the question is
We aren't qualifying it on our side so it hasn't gotten a stable/testing
set of branches.
-eric
On Tue, May 3, 2016 at 4:15 AM Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> +Eric Christopher
>
> Adding Eric as he was the last person merging changes to the google/stable
> br
https://llvm.org/bugs/show_bug.cgi?id=27634
Bug ID: 27634
Summary: Spelling fixes for lldb
Product: lldb
Version: 3.8
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Co
11 matches
Mail list logo
