I wonder if this should go in LLVM?
On Fri, Jun 2, 2017 at 7:35 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
> Herald added subscribers: mgorny, emaste.
>
> It is intended to wrap functions which can fail with EINTR (which we
> have a surprisin
Maybe just ask on llvm dev what people's thoughts are?
On Fri, Jun 2, 2017 at 7:51 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath updated this revision to Diff 101212.
> labath added a comment.
>
> - fix freebsd typo
> - use ::waitpid consistently
>
>
> https://reviews
Author: zturner
Date: Tue Jun 6 22:48:56 2017
New Revision: 304864
URL: http://llvm.org/viewvc/llvm-project?rev=304864&view=rev
Log:
Move Object format code to lib/BinaryFormat.
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and
Note that even simpler would be
```
return llvm::find_if(col, in_range_predicate) != col.end();
```
On Thu, Jun 8, 2017 at 4:50 PM Davide Italiano via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: davide
> Date: Thu Jun 8 18:49:56 2017
> New Revision: 305035
>
> URL: http://llvm.
I had actually been considering going the other way. Moving connection and
all implementations to Utility. Host is a big contributor to the dependency
problems, so putting more stuff in seems like the wrong direction.
The end state i had in mind was similar to llvm support (which is more less
the
courage a factory-like pattern
On Tue, Jun 20, 2017 at 7:00 AM Pavel Labath wrote:
> On 20 June 2017 at 14:28, Zachary Turner wrote:
> > I had actually been considering going the other way. Moving connection
> and
> > all implementations to Utility. Host is a big contributor to t
Author: zturner
Date: Tue Jun 20 20:52:37 2017
New Revision: 305873
URL: http://llvm.org/viewvc/llvm-project?rev=305873&view=rev
Log:
Fix a python object leak in SWIG glue.
PyObject_CallFunction returns a PyObject which needs to be
decref'ed when it is no longer needed.
Patch by David Luyer
Diff
No objections here
On Fri, Jun 23, 2017 at 5:48 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
> Herald added a subscriber: mgorny.
>
> The new UndefinedBehaviorSanitizer plugin was breaking file path length
> limits, because it's (fairly long na
Author: zturner
Date: Fri Jun 23 18:55:32 2017
New Revision: 306186
URL: http://llvm.org/viewvc/llvm-project?rev=306186&view=rev
Log:
Fix LLDB build.
This was broken due to directly including windows.h, which
caused a problem when someone in LLVM called std::min in a header
file. LLDB has a wind
Can you run the analyze deps script before and after this patch, and update
the cmake files if any deps are no longer necessary?
On Mon, Jun 26, 2017 at 8:24 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
> Herald added subscribers: mgorny, kubam
Cool, lgtm
On Thu, Jun 29, 2017 at 5:52 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath updated this revision to Diff 104624.
> labath added a comment.
>
> That's a good idea. This time I almost smuggled in a (unused) Host include
> into
> Utility -- it was a leftover f
Author: zturner
Date: Sun Jul 9 16:32:15 2017
New Revision: 307512
URL: http://llvm.org/viewvc/llvm-project?rev=307512&view=rev
Log:
Don't access Python objects while not holding the GIL.
Patch by Tatyana Krasnukha
Differential Revision: https://reviews.llvm.org/D34942
Modified:
lldb/trunk
I am OOO for another week, can you add jingham or clayborg instead?
On Thu, Jul 20, 2017 at 11:40 AM Jessica Han via Phabricator <
revi...@reviews.llvm.org> wrote:
> jessicah added reviewers: tfiala, zturner.
> jessicah added a comment.
>
> Todd, Zachary,
>
> Can you help review this change?
>
> T
Does this evaluate to nothing if curses is not present?
On Sat, Aug 5, 2017 at 9:15 AM Michał Górny via Phabricator <
revi...@reviews.llvm.org> wrote:
> mgorny updated this revision to Diff 109879.
> mgorny added a comment.
>
> Forgive my poor eyesight, obviously this could go into existing LINK_L
ALL, ".932") => nullptr) in
> Darwin, Linux, and FreeBSD and want to make sure I'm not misunderstanding
> something about how this test works. Do I understand this test correctly?
>
> Thanks for your input!
> -Tim
>
>
> On Fri, Feb 17, 2017 at 7:42 AM, Zachary
StringSwitch doesn't create any std::strings (doing so would allocate
memory), but it does do the memcmp. Unless it's in a hot path I think
optimizing for readability is the right choice.
On Tue, Sep 5, 2017 at 2:02 PM Jason Molenda wrote:
>
>
> > On Sep 5, 2017, at 1:34 PM, Davide Italiano
>
I noticed you said it generates new and delete. I find that strange, we
should look into why that's happening because it's not supposed to be.
On Tue, Sep 5, 2017 at 2:07 PM Zachary Turner wrote:
> StringSwitch doesn't create any std::strings (doing so would allocate
> me
Ok last message. I bet it's because the patch writes std::string
Name(reg_info->Name);
change this to StringRef and it should be fine. I'd be curious to see how
many instructions that generates.
On Tue, Sep 5, 2017 at 2:12 PM Zachary Turner wrote:
> I noticed you said it g
Unless it's showing up on a profile, isn't all of this just a solution
looking for a problem? Davide claims neither the original or updated code
shows up on any profiles, so why don't we just default to readable?
On Tue, Sep 5, 2017 at 3:17 PM Greg Clayton wrote:
> We should actually populate t
handles registers is
> one of the less well-designed parts of the debugger and it's something I
> often think about in the back of my mind, how it could possibly be done
> better than it is today. You can see me experimenting with an idea with
> the RegisterNumber class I use in
On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
>
> I know there is debate about this one side and another but for lldb this
> is a settled issue. Unless you really are in a state where the world is
> about to come crashing down around you, you can't r
Note that if something originates from user input, then i agree there's no
excuse for a fail fast. But after all the inputs have been sanitized, I
think it's fine to fast fail
On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner wrote:
> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham vi
On Fri, Sep 8, 2017 at 8:19 PM Jason Molenda wrote:
> Also keep in mind that debug sessions have a tendency to be long lived. I
> may be working through a problem for half an hour -- or this may be the one
> rare instance where a bug reproduces -- and crashing because some bogus
> piece of debug
On Sat, Sep 9, 2017 at 11:18 AM Jim Ingham wrote:
> On Sep 8, 2017, at 11:45 PM, Zachary Turner wrote:
>
> On Fri, Sep 8, 2017 at 8:19 PM Jason Molenda wrote:
>
>> Also keep in mind that debug sessions have a tendency to be long lived.
>> I may be working through a
On Sat, Sep 9, 2017 at 12:04 PM Jim Ingham wrote:
>
> I disagree here. If you can reasonably unwind from an error you should do
> so even if you can’t figure out how you could have gotten an answer you
> didn’t expect. If an API is returning a pointer to something you should
> assume it might r
formed object file might seem a good way to ensure that you don’t have
> to make guesses that might lead you astray. But the people who need to
> load core files on OS X are rightly unmoved by such arguments if lldb
> disappears out from under them when reading in core files.
>
> Jim
On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> I know there are two points of view here so I will give my two cents:
>
> If it comes down to something as easy as "always check for NULL before
> doing something", or something that is similar an
Maybe I'm missing something, but Why can't you just not generate a
relocation that the JIT doesn't handle?
On Mon, Sep 11, 2017 at 3:43 PM Greg Clayton wrote:
>
> On Sep 11, 2017, at 3:37 PM, Zachary Turner wrote:
>
> On Mon, Sep 11, 2017 at 3:31 PM Greg Clayto
On Mon, Sep 11, 2017 at 4:22 PM Jason Molenda via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> fwiw the reason the JIT came up is because we had an instance where the
> older MCJIT wasn't handling a relocation in thumb code about six weeks ago
> and we only caught the crash a couple days b
hing is not acceptable. I can't believe we have to keep saying this.
>
> On Sep 11, 2017, at 4:39 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>
>
> On Mon, Sep 11, 2017 at 4:22 PM Jason Molenda via lldb-commits <
> lldb-commits@li
e project.
On Tue, Sep 12, 2017 at 9:53 AM Zachary Turner wrote:
> If you had just logged it, the bug would still not be fixed because nobody
> would know about it. I also can't believe we have to keep saying this :-/
>
> On Tue, Sep 12, 2017 at 9:50 AM Greg Clayton wrote:
>
On Tue, Sep 12, 2017 at 10:03 AM Greg Clayton wrote:
> On Sep 12, 2017, at 9:53 AM, Zachary Turner wrote:
>
> If you had just logged it, the bug would still not be fixed because nobody
> would know about it. I also can't believe we have to keep saying this :-/
>
>
On Tue, Sep 12, 2017 at 11:07 AM Greg Clayton wrote:
>
> On Sep 12, 2017, at 10:10 AM, Zachary Turner wrote:
>
>
>
> On Tue, Sep 12, 2017 at 10:03 AM Greg Clayton wrote:
>
>> On Sep 12, 2017, at 9:53 AM, Zachary Turner wrote:
>>
>> If you had just logg
On Tue, Sep 12, 2017 at 1:04 PM Jim Ingham wrote:
>
> I don't see any evidence for lldb suffering from "a huge class of bugs
> that we are willfully ignoring..." particularly ones that would be easily
> caught if we just had more asserts. Can you give some examples?
>
Probably all of these, for
(Some of those look like correct fixes btw, since they deal with user input)
On Tue, Sep 12, 2017 at 1:16 PM Zachary Turner wrote:
> On Tue, Sep 12, 2017 at 1:04 PM Jim Ingham wrote:
>
>>
>> I don't see any evidence for lldb suffering from "a huge class of b
at reducing the prevalence of the ONE signal that tells you
exactly where test coverage is lacking.
On Tue, Sep 12, 2017 at 1:17 PM Zachary Turner wrote:
> (Some of those look like correct fixes btw, since they deal with user
> input)
>
> On Tue, Sep 12, 2017 at 1:16 PM Zachary Turner
serts they fixes for lldb
> not remembering that it has to tread carefully to avoid triggering other
> asserts elsewhere.
>
> Jim
>
> > On Sep 12, 2017, at 1:17 PM, Zachary Turner wrote:
> >
> > (Some of those look like correct fixes btw, since they deal with user
> i
On Tue, Sep 12, 2017 at 1:30 PM Jim Ingham wrote:
> Can you elaborate on this comment. I must be being dense but it didn't
> parse for me.
>
> Jim
>
git log --stat shows you the files that were changed as part of the CL. If
I re-run that command with --stat, out of the first 30 CLs, only 1 had
Right, and the only reason it's a bigger problem is because of test
coverage.
On Tue, Sep 12, 2017 at 2:34 PM Jason Molenda wrote:
>
>
> > On Sep 12, 2017, at 11:19 AM, Zachary Turner wrote:
> >
> >
> >
> > On Tue, Sep 12, 2017 at 11:07 AM Greg C
r on the test coverage part, don't think you'll
> get any pushback on that front.
>
> On Sep 12, 2017, at 2:36 PM, Zachary Turner wrote:
>
> Right, and the only reason it's a bigger problem is because of test
> coverage.
>
> On Tue, Sep 12, 2017 at 2:34
Author: zturner
Date: Thu Sep 14 09:47:58 2017
New Revision: 313270
URL: http://llvm.org/viewvc/llvm-project?rev=313270&view=rev
Log:
[lit] Force site configs to be run before source-tree configs
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always
Author: zturner
Date: Thu Sep 14 19:56:40 2017
New Revision: 313335
URL: http://llvm.org/viewvc/llvm-project?rev=313335&view=rev
Log:
Revert "[lit] Force site configs to run before source-tree configs"
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix
Author: zturner
Date: Fri Sep 15 15:10:46 2017
New Revision: 313407
URL: http://llvm.org/viewvc/llvm-project?rev=313407&view=rev
Log:
Resubmit "[lit] Force site configs to run before source-tree configs"
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were
On Mon, Sep 18, 2017 at 3:13 PM Leonard Mosescu wrote:
> It's a good question - here's a two part answer:
>
> 1. The actual printing of the output is the longest blocking in many cases
> (as mentioned in the description: the actual data gathering for "target
> module dump symtab" can take 1-2sec,
rough, then you
> might also want to write a unit test for the underlying C++ API's. But in
> this case the SB function will just call the underlying CommandInterpreter
> one, so testing at the SB layer is sufficient.
>
> Jim
>
> > On Sep 19, 2017, at 10:45 AM, Zachary
Also, it avoids polluting the SB interface with another function that
probably nobody is ever going to use outside of testing. Adding to the SB
API should take an act of God, given that once it gets added it has to stay
until the end of time.
On Tue, Sep 19, 2017 at 11:15 AM Zachary Turner
way to construct a MemoryBuffer from a StringRef, or to use the
> line_iterator directly with a StringRef.
>
>
> On Tue, Sep 19, 2017 at 10:39 AM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> zturner added a comment.
>>
>> Give
On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham wrote:
> We agreed to forwards compatibility because people write big scripts that
> use the SB API, implement GUI's on top of them (more than just Xcode) etc.
> So we try not to jerk those folks around. That adds a little more
> responsibility on our
On Tue, Sep 19, 2017 at 11:34 AM Jim Ingham wrote:
>
> > On Sep 19, 2017, at 11:30 AM, Zachary Turner wrote:
> >
> >
> >
> > On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham wrote:
> > We agreed to forwards compatibility because people write big scripts
> t
On Tue, Sep 19, 2017 at 11:40 AM Jim Ingham wrote:
> I must be missing something.
>
> DisaptchInputInterrupt knows how to interrupt a running process, and
> because of Enrico's Python interruption stuff it will interrupt script
> execution at some point but it wasn't very reliable last time I tri
On Tue, Sep 19, 2017 at 11:51 AM Zachary Turner wrote:
> On Tue, Sep 19, 2017 at 11:40 AM Jim Ingham wrote:
>
>> I must be missing something.
>>
>> DisaptchInputInterrupt knows how to interrupt a running process, and
>> because of Enrico's Python interrup
On Tue, Sep 19, 2017 at 7:12 PM Jason Molenda wrote:
>
>
> > On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> >
> >
> > After some additional thought, I stilled think testing below the sb api
&
On Wed, Sep 20, 2017 at 10:33 AM Jim Ingham wrote:
> One of the fundamental goals of lldb is that it be an extensible
> debugger. The extension mechanism for command line lldb all runs through
> the SB API through either Python or C++ (though most folks choose to use
> Python). We know first ha
On Wed, Sep 20, 2017 at 10:46 AM Jim Ingham wrote:
> Directly WRT testing. I’m not against ALSO adding gtests when you add
> some functionality. But when your change is actually adding behaviors to
> lldb, one of the things you need to ask yourself is if this is
> functionality that extension d
On Wed, Sep 20, 2017 at 11:14 AM Jim Ingham wrote:
>
> The amount of test coverage lldb has at present has much more to do with
> the very aggressive schedules lldb has been driven by since its inception
> than any difficulties with writing tests IMHBSEO.
>
This probably applies to the folks at
Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it just
release at the end of the function?
On Sun, Oct 15, 2017 at 2:42 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
>
> We had a bug where if we had forked (in the ProcessLau
something (which i very well could be)
On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath wrote:
> On 15 October 2017 at 23:04, Zachary Turner wrote:
> > Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it
> just
> > release at the end of the function?
>
>
>
On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath wrote:
> On 15 October 2017 at 23:04, Zachary Turner wrote:
> > Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it
> just
> > release at the end of the function?
>
>
> The thing is, it is unable to ac
> state they had left in the new process. Regarding execve it doesn't do fork
> so we would have to do fork & execve what have the same issue (actually we
> are using execve as of now but it isn't different from exec in this regard).
>
> Tamas
>
> On Mon, Oct 16,
Ahh wait, sorry. I meant posix_spawn, not execve
On Mon, Oct 16, 2017 at 2:16 PM Zachary Turner wrote:
> I guess what I mean is, my understanding is that the only "advantage" (if
> you can even call it that) of using fork + exec over execve is that fork +
> exec allows yo
New patch is fine. Lgtm
On Thu, Oct 19, 2017 at 4:56 AM Ana Julia Caetano via Phabricator <
revi...@reviews.llvm.org> wrote:
> anajuliapc added inline comments.
>
>
>
> Comment at:
> source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp:327-333
> + for (uint32_t i =
+jingham
On Fri, Oct 20, 2017 at 6:57 AM Don Hinton via Phabricator <
revi...@reviews.llvm.org> wrote:
> hintonda added a comment.
>
> In https://reviews.llvm.org/D36347#901885, @zturner wrote:
>
> > One possible reason for why this never got any traction is that
> `lldb-commits` wasn't added as
Indeed, that was my point.
As an aside, clang has the —driver-mode option that lets you specify either
gcc or g++, which is in turn equivalent to running clang.exe vs
clang++.exe. Does gcc have this? If so we can require it to be the non ++
version, and then build the driver mode argument as neces
Also worth noting is that the lit site config files only matter for 3-4
tests, which I don’t believe are run anywhere. I plan to overhaul this
whole system in the coming weeks/months, so personally I don’t mind much if
it breaks
On Mon, Oct 23, 2017 at 6:17 PM Zachary Turner via Phabricator <
r
If that works, let’s just do that. I would much rather make definite
forward progress towards the desired end state than support something
nobody even uses
On Mon, Oct 23, 2017 at 8:24 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://revie
I think there's something like lit.util.which(), or a similar function in
lldb test utilities. Seems like we could solve this by writing the
function:
```
def is_exe(fpath):
if not os.path.exists(fpath):
fpath = lit.util.which(fpath)
if not (fpath and os.path.exists(fpath)):
Actually there's fewer, I think `test/testcases` is a symlink. But there's
more than one, for sure. We should standardize on the one in lldbutil.py
On Tue, Oct 24, 2017 at 9:33 AM Davide Italiano
wrote:
> Fun fact, there are 13 implementations in tree of is_exe (and probably
> which). Maybe we
On Wed, Oct 25, 2017 at 4:59 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> Note, BTW, we absolutely need some way to say "this symbol from this
> library". But first of all, if we're going to do this you need to be able
> to mix & match within an
at 9:30 AM Greg Clayton wrote:
>
> On Oct 25, 2017, at 6:05 PM, Zachary Turner wrote:
>
>
>
> On Wed, Oct 25, 2017 at 4:59 PM Jim Ingham via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> jingham added a comment.
>>
>> Note, BTW, we absolutel
Nothing happened internally. Usually people submit their own patches after
they're accepted. If neither of you have commit access though, then you'll
need to let us know so that we can submit on your behalf.
On Thu, Oct 26, 2017 at 11:30 AM Gustavo Serra Scalet via Phabricator <
revi...@reviews.
Seems fine, it would be nice if the workflow could be improved a little bit
so that all you have to do is say `clangdiag break
—error=“-Wcovered-switch”` or something . I think that gives the most
intuitive usage for people, even it’s a bit harder to implement.
I also think user shouldn’t really h
I think you now need to use `-DLLDB_TEST_C_COMPILER` and
`-DLLDB_TEST_CXX_COMPILER`
On Thu, Oct 26, 2017 at 4:40 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:
> probinson added a comment.
>
> Has this gone in? I'm wondering because I starting playing with the
> monorepo, ra
bly end up very
> ugly).
>
> On 26 October 2017 at 16:50, Zachary Turner wrote:
> > I think you now need to use `-DLLDB_TEST_C_COMPILER` and
> > `-DLLDB_TEST_CXX_COMPILER`
> >
> > On Thu, Oct 26, 2017 at 4:40 PM Paul Robinson via Phabricator
> > wrote:
On Thu, Oct 26, 2017 at 3:18 PM Don Hinton wrote:
> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner
> wrote:
>
>> Seems fine, it would be nice if the workflow could be improved a little
>> bit so that all you have to do is say `clangdiag break
>> —error=“-Wcovere
5:44 PM, Zachary Turner
> wrote:
>
>>
>>
>> On Thu, Oct 26, 2017 at 3:18 PM Don Hinton wrote:
>>
>>> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner
>>> wrote:
>>>
>>>> Seems fine, it would be nice if the workflow could be
On Fri, Oct 27, 2017 at 2:13 PM Jason Molenda wrote:
> haven't had a chance to look at the patch yet, but just to comment on one
> part from Zach:
>
> > On Oct 27, 2017, at 2:06 PM, Zachary Turner via Phabricator via
> lldb-commits wrote:
> >
> >
> >
On Mon, Oct 30, 2017 at 5:32 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> In https://reviews.llvm.org/D39436#911304, @hintonda wrote:
>
> > In https://reviews.llvm.org/D39436#911274, @jingham wrote:
> >
> > > BTW, to Z's comment: you can't really
On Mon, Oct 30, 2017 at 5:47 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> In https://reviews.llvm.org/D39436#911305, @zturner wrote:
>
> > In https://reviews.llvm.org/D39436#911302, @hintonda wrote:
> >
> > > In https://reviews.llvm.org/D39436#911
Asking again, but why can’t this be done in th the script for clangdiag?
For example, there’s no tests for any of this in this patch. And it seems
likely that it will be rarely used anyway. So I’m still not convinced the
option-pollution and increased long term code maintenance burden of this
under
The takeaway from this example is nothing we don't already know. We need
better test coverage.
On Tue, Oct 31, 2017 at 8:08 AM Greg Clayton via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> This is one example of how StringRef causes issues because it was adopted
> everywhere. Is there an
this particular bug. Someone
returned a pointer to stack memory. That's a pretty common class of bug.
Actually though, I did think of another thing we learn from this example.
We should be running LLDB under ASAN
On Tue, Oct 31, 2017 at 8:12 AM Zachary Turner wrote:
> The takeaway fro
On Tue, Oct 31, 2017 at 8:12 AM Don Hinton wrote:
> There have been a few suggestions that I could just use a script to solve
> this "problem" -- poor startup performance of clangdiag.
>
> However, this patch was not submitted to solve a particular problem. It
> was submitted in response to Jim'
On Tue, Oct 31, 2017 at 8:20 AM Pavel Labath wrote:
> On 31 October 2017 at 15:12, Zachary Turner via lldb-commits
> wrote:
> > The takeaway from this example is nothing we don't already know. We need
> > better test coverage.
> Actually, this was caught by a tes
roid tests are now runinng lldb-server built with libc++ (which
> is how I found the bug). Eventually (= probably not this year) I may
> switch the host lldb as well.
>
> On 31 October 2017 at 15:41, Zachary Turner wrote:
> >
> >
> > On Tue, Oct 31, 2017 at 8:20 AM Pa
On Tue, Oct 31, 2017 at 9:00 AM Greg Clayton wrote:
> My main questions is: is there anything we can do to catch these things
> now that we have them.
>
Absolutely. Get bots running check-lldb with ASAN instrumented LLDB. I'm
going to go out on a limb and say you will find not just these bugs,
tions.
On Tue, Oct 31, 2017 at 8:32 AM Don Hinton wrote:
> Btw, is there a way to pass the '-m' option via the SB API? I'd like to
> exclude matches in comments when using BreakpointCreateBySourceRegex.
>
> On Tue, Oct 31, 2017 at 8:26 AM, Don Hinton wrote:
>
>>
On Tue, Oct 31, 2017 at 10:43 AM Jim Ingham wrote:
>
>
> > On Oct 31, 2017, at 9:05 AM, Zachary Turner wrote:
> >
> > This is a case where I think a new API *would* be warranted. But it
> would not be an API specifically for the -m option. It would instead be
Yes I expect someone else to review more thoroughly, but I included you
anyway since you may have to dtart caring about this soon :)
On Wed, Jan 9, 2019 at 6:39 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> Is there any chance we can get someone w
Author: zturner
Date: Wed Jan 9 13:20:44 2019
New Revision: 350764
URL: http://llvm.org/viewvc/llvm-project?rev=350764&view=rev
Log:
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It
Author: zturner
Date: Wed Jan 9 15:26:50 2019
New Revision: 350773
URL: http://llvm.org/viewvc/llvm-project?rev=350773&view=rev
Log:
Write PDB/variables.test to be more robust.
CHECK-DAG can't really be mixed with CHECK-NEXT statements because
each non DAG check sets a new search-origin for foll
Author: zturner
Date: Thu Jan 10 12:57:32 2019
New Revision: 350888
URL: http://llvm.org/viewvc/llvm-project?rev=350888&view=rev
Log:
[NativePDB] Add support for parsing typedef records.
Typedefs are represented as S_UDT records in the globals stream. This
creates a strange situation where "types
Author: zturner
Date: Thu Jan 10 12:57:50 2019
New Revision: 350889
URL: http://llvm.org/viewvc/llvm-project?rev=350889&view=rev
Log:
Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.
The function SymbolFile::ParseTypes previously accepted a SymbolContext.
This makes it extremely difficu
Author: zturner
Date: Fri Jan 11 10:03:20 2019
New Revision: 350943
URL: http://llvm.org/viewvc/llvm-project?rev=350943&view=rev
Log:
[SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.
Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a Sy
Author: zturner
Date: Fri Jan 11 10:35:58 2019
New Revision: 350950
URL: http://llvm.org/viewvc/llvm-project?rev=350950&view=rev
Log:
Fix build breaks after the ParseCompileUnit changes.
The addition of SymbolFileBreakpad crossed paths with my change,
so this interface needs to be fixed up as wel
Author: zturner
Date: Mon Jan 14 14:40:41 2019
New Revision: 351131
URL: http://llvm.org/viewvc/llvm-project?rev=351131&view=rev
Log:
[SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.
This method took a SymbolContext but only actually cared about the
case where the m_function membe
Author: zturner
Date: Mon Jan 14 14:41:00 2019
New Revision: 351132
URL: http://llvm.org/viewvc/llvm-project?rev=351132&view=rev
Log:
[SymbolFile] Remove the SymbolContext parameter from FindNamespace.
Every callsite was passing an empty SymbolContext, so this parameter
had no effect. Inside the
Author: zturner
Date: Mon Jan 14 14:41:21 2019
New Revision: 351133
URL: http://llvm.org/viewvc/llvm-project?rev=351133&view=rev
Log:
[SymbolFile] Remove SymbolContext parameter from FindTypes.
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the
Note that the PDB code runs on all platforms, not just Windows. You can
reproduce it by just running the affected test on darwin, as long as you've
built lld.
On Wed, Jan 16, 2019 at 8:50 AM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> On 16/01/2019 17:38, Adrian Prantl
The idea behind seven is that it’s a place to put stuff that we need for
py2/py3 interoperability that doesn’t already exist in six. Yes, maybe
there’s only one thing there now, but there could be more over time.
At least that was the thinking when I created it.
It seems like there’s two separate
Huh, that’s a coincidence. I chose the name because it was “like six”, but
I guess someone else chose it for the same reason
On Sat, Jan 26, 2019 at 2:18 PM Jonas Devlieghere
wrote:
>
>
> On Fri, Jan 25, 2019 at 8:44 PM Zachary Turner via lldb-commits <
> lldb-commits@lists.
401 - 500 of 3010 matches
Mail list logo
