It looks like we are triggering an assert in llvm on a debug build. I'll
try to track this down ASAP.
On 18 April 2017 at 21:24, Scott Smith via lldb-dev wrote:
> I'm trying to make sure some of my changes don't break lldb tests, but I'm
> having trouble getting a clean run even with a plain ch
Yeah I found the buildbot instance for lldb on Ubuntu 14.04, but it looks
like it is only running release builds. Is that on purpose?
On Wed, Apr 19, 2017 at 3:59 AM, Pavel Labath wrote:
> It looks like we are triggering an assert in llvm on a debug build. I'll
> try to track this down ASAP.
>
>
Hi,
Firstly, I am new to the community, So please bear with my mistakes and
guide me to be on your wavelength.
While using lldb we found the small bug with attaching to the running
process.
"attach" works fine when we run the lldb on the same dir where we ran the
executable but not if the dir chan
Hey,
I'm exploring using lldb-mi and lldb-server to remotely debug a process
running on a Linux host. I'm running into an issue where lldb-mi is
failing to load the ELF section headers from the remote process's memory
for certain shared libraries.
Looking at ObjectFileELF:GetSectionHeaderInfo I
On 19.04.2017 16:15, vignesh balu via lldb-dev wrote:
> Hi,
> Firstly, I am new to the community, So please bear with my mistakes and
> guide me to be on your wavelength.
>
> While using lldb we found the small bug with attaching to the running
> process.
> "attach" works fine when we run the lld
It is on purpose, although whether that purpose is worthwhile is
debatable...
We chose to run release builds there so to align the bots closer to the
binaries we release. Unfortunately, it does mean we run into situations
like these...
In any case, I have now a patch up for fixing one of the cras
No, this was an inadvertent side effect of rewriting the command parser to use
llvm's StringRef's. Please file a bug (or submit a patch!)
Jim
> On Apr 18, 2017, at 10:49 PM, via lldb-dev wrote:
>
> Hello,
>
> The query to repeat a command from history used to be ! but
> it looks like that d
> On Apr 19, 2017, at 7:37 AM, Pavel Labath via lldb-dev
> wrote:
>
> It is on purpose, although whether that purpose is worthwhile is debatable...
>
> We chose to run release builds there so to align the bots closer to the
> binaries we release. Unfortunately, it does mean we run into situat
A combination of:
1. Updating to a known good release according to buildbot
2. using Ubuntu 14.04
3. compiling release using clang-4.0
4. using the dotest command line that buildbot uses
5. specifying gcc-4.8 instead of the locally compiled clang
has most of the tests passing, with a handful of un
It looks like it was this change:
commit 45fb8d00309586c3f7027f66f9f8a0b56bf1cc4a
Author: Zachary Turner
Date: Thu Oct 6 21:22:44 2016 +
Convert UniqueCStringMap to use StringRef.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@283494
91177308-0d34-0410-b5e6-96231b3b80d8
The change was made to make the interface safer and allow propagation of
StringRef through other layers. The previous code was already taking a
const char *, and so it was working under the assumption that the const
char* passed in came from a ConstString. As such, continuing to make that
same as
I'll take a look
On Wed, Apr 19, 2017 at 10:33 AM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> No, this was an inadvertent side effect of rewriting the command parser to
> use llvm's StringRef's. Please file a bug (or submit a patch!)
>
> Jim
>
> > On Apr 18, 2017, at 10:49 PM, vi
Scratch that, looks like you already fixed this.
On Wed, Apr 19, 2017 at 4:50 PM Zachary Turner wrote:
> I'll take a look
>
> On Wed, Apr 19, 2017 at 10:33 AM Jim Ingham via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> No, this was an inadvertent side effect of rewriting the command parser
Yeah, source-code twiddling of thumbs while waiting for a build to complete...
Jim
> On Apr 19, 2017, at 4:51 PM, Zachary Turner wrote:
>
> Scratch that, looks like you already fixed this.
>
> On Wed, Apr 19, 2017 at 4:50 PM Zachary Turner wrote:
> I'll take a look
>
> On Wed, Apr 19, 2017
If I just assume the pointers are from ConstString, then doesn't that
defeat the purpose of making the interface safer? Why not use an actual
ConstString and provide conversion operators from ConstString to
StringRef? Seems we should be able to rely on the type system to get us
safety and perform
It doesn't entirely defeat the purpose, it's just not *as good* as making
the interfaces take ConstStrings. StringRef already has a lot of safety
and usability improvements over raw char pointers, and those improvements
don't disappear just because you aren't using ConstString. Although I
agree t
Created Review : https://reviews.llvm.org/D32271
Do i need to assign the reviewers ? if so please let me know how to get
reviewers list.
-vbalu
On Wed, Apr 19, 2017 at 7:59 PM, Kamil Rytarowski wrote:
> On 19.04.2017 16:15, vignesh balu via lldb-dev wrote:
> > Hi,
> > Firstly, I am new to the
17 matches
Mail list logo
