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
I do think at some point we will need to break up Host, but whether the
best way is to move stuff into Utility or to somewhere else is an open
question. Host also depends on Target, Symbol, process plugins, and various
other things. So we will need a way to group together all the stuff in Host
that
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
> memory), but it does do t
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 generates new and del
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
The C-string table and strcmp solution is fine, but I think the
StringSwitch method is strictly better. It's both faster (although I think
we agreed that speed doesn't matter in this case) //and// more readable.
Another alternative would be:
constexpr StringRef Registers[] = {"r12", "r13", "r14",
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 via Phabricator <
> revi
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 problem for half an hour -- o
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
Sure, but reading a core file involves handling user input. Obviously that
has to be sanitized and you can't crash on user input. I don't think
there's ever been any disagreement about that. On the other hand, if you
just type an expression in the debugger and expect an answer back, after
clang say
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 Clayton via lldb-commits <
> lldb-commit
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
>> Success? No. Log something. Return an error. Anything but crashing.
>> Crashing 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>
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 :-/
>
>
> By log, I mean Host::SystemL
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 logged it, the bug would still not be fixed be
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 bugs
>> that we are willfully ignoring
Incidentally, if you add --stat to the command line there, you'll see that
only 1 of those CLs has any test coverage at all. I pressed Enter a few
more times and I couldn't find any more tests.
If you want to look into reducing crashes, that's where you should be
looking. Not at reducing the pre
4ad5334bfcff803f3765e444785b8f9d3a73c683: Don't pass a null StringRef.
simple.
f7b079263a751fdf3adea8e549803aaf92d465f8: Maybe fix it instead, as the
comment suggests?
f3647763b02ddef65c6244f91939d997f7733ecd: Probably fine since you don't
have control over the code of the plugin.
f67e0b92fbd9e0bc
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 Clayton
> wrote:
> >
> >> On Sep 12, 2017,
So let's say that in a hypothetical future we had very good test coverage.
Would there still be resistance to asserts? Because if your test coverage
is good, then your bots should be catching most stuff.
On Tue, Sep 12, 2017 at 2:42 PM Greg Clayton wrote:
> Agreed. We need to do better on the t
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,
That would work, but I think it's adding many more pieces to the test. Now
there's threads, a Python layer, and multiprocess dotest infrastructure in
the equation. Each providing an additional source of flakiness and
instability.
If all it is is a pass-through, then just calling the function it
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 wrote
Right, I can fix that. Give me a few minutes though.
On Tue, Sep 19, 2017 at 11:28 AM Leonard Mosescu wrote:
> This looks beautiful indeed. The problem is that it doesn't quite work
> with the current MemoryBuffer and the line_iterator : for one thing there's
> no way to construct a MemoryBuffe
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
> that use the SB API, implement GUI's on top
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 interruption stuff it will interrupt script
>> ex
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
what are we using fork for, out of curiosity? It seems pretty hard to make
this work. Logging isn’t the only thing in the program that might be
holding a mutex, so it seems like this could still happen.
Seems like mixing fork and mutexes is just a fundamentally bad idea, unless
I’m missing somet
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 acquire the lock in the first pla
> 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,
cve 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, 2017 at 1:57 PM Zachary Turner via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
&
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 <
revi.
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
Note that $ is a valid character in a MSVC-mangled symbol name. So, I
don't think it will work for that reason alone. FWIW, I also don't like
the {,,} syntax very much, but if you read on there's a simpler ! syntax
that is pretty nice.
libfoo!symbolname
On Thu, Oct 26, 2017 at 9:30 AM Greg Cla
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
Ahh, sorry. While I feel strongly about 1 long term, going from 4 -> 2 is
already a win, so I see no reason to block this over that. We can then
work on going from 2 -> 1 later.
On Thu, Oct 26, 2017 at 4:57 PM Pavel Labath wrote:
> I haven't put this in yet. I was still waiting for a reaction
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=“-Wcovered-switch”` or something . I think
looks good! Feel free to commit whenever, I'd definitely recommend posting
a PSA on cfe-dev@ (after you commit) so that people know about it. You
might also get some useful ideas for improvements that way too.
On Thu, Oct 26, 2017 at 9:52 PM Don Hinton wrote:
> On Thu, Oct 26, 2017 at 5:44 PM,
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:
> >
> >
> >
> > Comment at: source/Targe
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
It's worth mentioning again that LLVM uses StringRef pretty pervasively and
doesn't have issues. There's nothing fundamentally different about
debuggers that makes StringRefs bad whereas they can be good in other types
of software. If we really wanted to avoid use-after-frees we would pick a
lang
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
vel 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.
> >>
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,
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 an API
that introduces an `SBBreakpointOptions` class, and then add a method
called `BreakpointCreateWithOptions(options)`.
Note that the general policy of
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 an
> API that introduces an `SBBre
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.
Author: zturner
Date: Tue Jan 29 14:55:21 2019
New Revision: 352557
URL: http://llvm.org/viewvc/llvm-project?rev=352557&view=rev
Log:
Fix some warnings in building LLDB.
Differential Revision: https://reviews.llvm.org/D57413
Modified:
lldb/trunk/source/Commands/CommandObjectReproducer.cpp
401 - 500 of 2276 matches
Mail list logo
