> On Sep 12, 2016, at 4:57 PM, Zachary Turner wrote:
>
>
>
> On Mon, Sep 12, 2016 at 4:19 PM Jim Ingham via lldb-commits
> wrote:
> Author: jingham
> Date: Mon Sep 12 18:10:56 2016
> New Revision: 281273
>
> URL: http://llvm.org/viewvc/llvm-project?rev=281
I see the whole content, but I'll reply to this one so the reply doesn't get
truncated on your end...
> On Sep 12, 2016, at 6:03 PM, Zachary Turner wrote:
>
>
> Immediately, very little. A small amount of performance, since comparing
> StringRefs is faster than comparing null terminated stin
BTW, I was going over these, and this does not seem to me like a case where you
want to do an early return.
The logic is:
Add some stuff to data
See if I found the UserSource key, if so add some more stuff
Then return data
It would not be clearer to do:
Add some stuff to data
See if I found th
Author: jingham
Date: Mon Sep 12 20:58:08 2016
New Revision: 281288
URL: http://llvm.org/viewvc/llvm-project?rev=281288&view=rev
Log:
Add a few const's (thanks Zachary) and return shared or unique pointers
in places where they help prevent leaks.
Modified:
lldb/trunk/include/lldb/Breakpoint/B
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Looks fine. The only bad effect of making a CommandBaton, then going out of
your way to put it in a plain old BatonSP before passing it to us rather than a
CommandBatonSP is that the serial
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
See inlined comments. Otherwise this is great.
Comment at: include/lldb/Core/SourceManager.h:34-35
@@ -33,3 +33,4 @@
public:
-File(const FileSpec &file_spe
Author: jingham
Date: Wed Sep 14 14:05:27 2016
New Revision: 281519
URL: http://llvm.org/viewvc/llvm-project?rev=281519&view=rev
Log:
Fix some const-ness issues with BreakpointID & BreakpointIDList.
Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointID.h
lldb/trunk/include/lldb/Breakp
Author: jingham
Date: Wed Sep 14 14:07:35 2016
New Revision: 281520
URL: http://llvm.org/viewvc/llvm-project?rev=281520&view=rev
Log:
Add SB API's for writing breakpoints to & creating the from a file.
Moved the guts of the code from CommandObjectBreakpoint to Target (should
have done it that way
jingham added a comment.
Writing tests this way means we're going back to testing the command line
commands. That was what gdb did for the most part, and you ended up terrified
of making changes that might effect command output, not because the change was
hard but because knew you would have t
> On Sep 14, 2016, at 4:00 PM, Zachary Turner wrote:
>
> On Wed, Sep 14, 2016 at 3:51 PM Sean Callanan wrote:
> How different is that really from
>
> (lldb) script lldb.frame.FindVariable("argc").GetValue()
> '1'
> (lldb) script lldb.process.GetNumThreads()
> 1
> (lldb) script lldb.process.Get
If the internal thing is three things in a list, you get back thing one, thing
two and thing three in declarative ways rather than "I got three space
separated things, maybe they had spaces in them, maybe there were quotes, etc,
and don't ever change this now or you'll have to go fix all the tes
> On Sep 14, 2016, at 3:56 PM, Chris Bieneman wrote:
>
> @jingham and @zturner, we can also take advantage of FileCheck's use of
> regular expressions to write robust matchers. In general LLVM has managed to
> change text output formats many times in radical ways, and LIT's testing has
> stil
Also, w.r.t:
> Aside from write imperative control flow constructs, which I see as a
> positive rather than a negative.
I wrote a bunch of tests to test that stepping behavior for swift and C was
reasonable. When stepping through source code, there is not one correct way to
write the line ta
> On Sep 14, 2016, at 3:51 PM, Zachary Turner wrote:
>
> zturner added a comment.
>
> Also, it occurred to me that if all tests were like this (and yes, that's a
> tall order to imagine a world where not a single test was written using the
> Python API), we could probably actually drop the Py
> On Sep 14, 2016, at 5:13 PM, Zachary Turner wrote:
>
> I'm only saying that we should have an open mind. Obviously there are
> (valid!) concerns. If we can't solve them then we can't solve them. The
> goal (my goal anyway) is always to make things better, not to use X because
> it's X.
Author: jingham
Date: Wed Sep 14 20:47:22 2016
New Revision: 281569
URL: http://llvm.org/viewvc/llvm-project?rev=281569&view=rev
Log:
Make the keys enumerations for options and resolvers enum classes.
This keeps them from conflicting with other symbols names, so it's
worth their being less conven
Author: jingham
Date: Thu Sep 15 20:41:27 2016
New Revision: 281690
URL: http://llvm.org/viewvc/llvm-project?rev=281690&view=rev
Log:
First tests for serializing breakpoints.
Plus a few bug fixes I found along the way.
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpo
Author: jingham
Date: Tue Sep 20 17:54:49 2016
New Revision: 282036
URL: http://llvm.org/viewvc/llvm-project?rev=282036&view=rev
Log:
Add some more tests for breakpoint serialization.
Serialize breakpoint names & the hardware_requested attributes.
Also added a few missing affordances to SBBreakpo
Author: jingham
Date: Tue Sep 20 20:21:19 2016
New Revision: 282043
URL: http://llvm.org/viewvc/llvm-project?rev=282043&view=rev
Log:
Adds tests for breakpoint names, and a FindBreakpointsByName.
Also if you set a breakpoint with an invalid name, we'll
refuse to set the breakpoint rather than sil
Author: jingham
Date: Wed Sep 21 14:21:38 2016
New Revision: 282103
URL: http://llvm.org/viewvc/llvm-project?rev=282103&view=rev
Log:
Probably should add the breakpoint names test directory as well...
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_name
IIRC you said the llvm one doesn't support extended regular expressions. If
that's true, please don't do this till that is fixed. I think pretty much
everybody who is using reg expressions expects to be able to use extended
regular expressions.
Jim
> On Sep 21, 2016, at 4:58 PM, Zachary Turn
> On Sep 21, 2016, at 5:25 PM, Greg Clayton via lldb-commits
> wrote:
>
> Yep, and we can't have any regex objects in LLDB using those because they
> will only work on Apple and we don't want code like:
>
> #if defined(__APPLE__)
> RegularExpression e("\s+");
> #else
> RegularExpression e
It seems a little odd that llvm has its own forked copy of Henry Spencer's old
regular expression engine? Are there platforms we care about that don't have a
maintained version of exactly the same code?
Jim
> On Sep 21, 2016, at 5:42 PM, Zachary Turner wrote:
>
> I'll try to address the R
So does the build machinery use the one that is supported on that platform if
it is available? They are going to get much wider testing, fixes and even
"ENHANCE"ments...
Jim
> On Sep 21, 2016, at 6:07 PM, Zachary Turner wrote:
>
> Windows :)
>
> But that was before std::regex. In theory std
I was being facetious about the enhancements. I am more serious about bugs. I
would really rather use a maintained rather than a "I got this source at some
point and use it for some things, but don't rigorously test it" version of
regcomp & friends. Can we hold off on that change till we have
First off, I bet we could decide for giggles to make 5 or 6 random copies of
strings before we pass them to regcomp in lldb and none of our users would
notice the difference. It's just not something we do as a hot code path. So
avoiding a copy or two is not worth even one new bug in regex hand
I imagine Greg also thought the llvm classes were just a wrapper around the
system reg* functions. I wouldn't have had a problem with that, though it
wouldn't have made any noticeable difference to lldb's performance. But I
actually had to deal with a bug in the OS X copy of the regex engine t
Author: jingham
Date: Thu Sep 22 17:00:59 2016
New Revision: 282205
URL: http://llvm.org/viewvc/llvm-project?rev=282205&view=rev
Log:
Serilize the thread options within the breakpoint options.
Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h
lldb/trunk/include/lldb/Target/
Author: jingham
Date: Thu Sep 22 17:20:28 2016
New Revision: 282207
URL: http://llvm.org/viewvc/llvm-project?rev=282207&view=rev
Log:
Add the ability to deserialize only breakpoints matching a given name.
Also tests for this and the ThreadSpec serialization.
Modified:
lldb/trunk/include/lldb
Author: jingham
Date: Thu Sep 22 18:42:42 2016
New Revision: 282212
URL: http://llvm.org/viewvc/llvm-project?rev=282212&view=rev
Log:
Add the ability to append breakpoints to the save file.
Modified:
lldb/trunk/include/lldb/API/SBTarget.h
lldb/trunk/include/lldb/Target/Target.h
lldb/
jingham added a subscriber: jingham.
jingham added a comment.
As long as the only way you can specify the black-list is explicitly on the
command line, I think this is fine. There should never be implicit searches
for a backlist file. You must have to supply it each time you run the
testsuite
I think you missed some changes in Host.mm on OS X as well.
Jim
> On Sep 23, 2016, at 3:27 PM, Zachary Turner via lldb-commits
> wrote:
>
> Author: zturner
> Date: Fri Sep 23 17:27:03 2016
> New Revision: 282309
>
> URL: http://llvm.org/viewvc/llvm-project?rev=282309&view=rev
> Log:
> Fix bui
Author: jingham
Date: Fri Sep 23 17:36:00 2016
New Revision: 282311
URL: http://llvm.org/viewvc/llvm-project?rev=282311&view=rev
Log:
Mutatis mutandis for char * -> StringRef.
Modified:
lldb/trunk/source/Host/macosx/Host.mm
Modified: lldb/trunk/source/Host/macosx/Host.mm
URL:
http://llvm.o
Not done building yet, I also had to fetch a new llvm, but at least those were
needed.
Jim
> On Sep 23, 2016, at 3:47 PM, Zachary Turner wrote:
>
> Ahh nvm, I see you beat me to it. Thanks
>
> On Fri, Sep 23, 2016 at 3:47 PM Zachary Turner wrote:
> Thanks I'll take a look. I only saw the o
Author: jingham
Date: Mon Sep 26 14:47:37 2016
New Revision: 282432
URL: http://llvm.org/viewvc/llvm-project?rev=282432&view=rev
Log:
Fix serialization of Python breakpoint commands.
CommandData breakpoint commands didn't know whether they were
Python or Command line commands, so they couldn't se
Author: jingham
Date: Thu Sep 29 18:48:21 2016
New Revision: 282810
URL: http://llvm.org/viewvc/llvm-project?rev=282810&view=rev
Log:
Add some logging when trace is on. We're getting a bot failure on i386 that
doesn't
I can't reproduce locally. Hopefully this will help us catch the reason.
Mo
Author: jingham
Date: Thu Sep 29 20:23:46 2016
New Revision: 282830
URL: http://llvm.org/viewvc/llvm-project?rev=282830&view=rev
Log:
Add the tracking radar on our end.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/break_after_join/TestBreakAfterJoin.py
Modified
Author: jingham
Date: Fri Sep 30 17:07:41 2016
New Revision: 282966
URL: http://llvm.org/viewvc/llvm-project?rev=282966&view=rev
Log:
IsValid is the way to ask a breakpoint location whether it is valid.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint
Author: jingham
Date: Fri Sep 30 17:22:09 2016
New Revision: 282969
URL: http://llvm.org/viewvc/llvm-project?rev=282969&view=rev
Log:
Add the radar from our end to the bugreport string.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py
Modified
Author: jingham
Date: Fri Sep 30 17:24:11 2016
New Revision: 282970
URL: http://llvm.org/viewvc/llvm-project?rev=282970&view=rev
Log:
Add the radar on our end to the bugreport string.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/create_during_step/TestCreateDuri
Author: jingham
Date: Fri Sep 30 17:55:57 2016
New Revision: 282976
URL: http://llvm.org/viewvc/llvm-project?rev=282976&view=rev
Log:
Fix up the test so it gets closer to passing.
Remove the test for thread stopped states from this test.
That isn't set properly now, and its setting doesn't matt
Author: jingham
Date: Fri Sep 30 19:49:12 2016
New Revision: 282993
URL: http://llvm.org/viewvc/llvm-project?rev=282993&view=rev
Log:
Fix up this test case.
The lldbutil.run_break_set_by_file_and_line has already checked that the number
of
locations was 1, so don't check it again. And certainl
ldb-x86_64-ubuntu-14.04-android/builds/9655
>
> Thanks,
> Dimitar
>
> On Fri, Sep 30, 2016 at 11:07 PM, Jim Ingham via lldb-commits
> wrote:
> Author: jingham
> Date: Fri Sep 30 17:07:41 2016
> New Revision: 282966
>
> URL: http://llvm.org/viewvc/llvm-project?
Ah, okay, thanks!
Jim
> On Oct 3, 2016, at 1:44 PM, Pavel Labath wrote:
>
> The test fails on remote targets because it tries to set breakpoints based on
> remote paths. We'll have that fixed shortly.
>
> On 3 October 2016 at 11:13, Jim Ingham via lldb-commits
>
jingham added a comment.
You messed up the meaning of one comment (noted inline). Otherwise this looks
fine to me too.
> Args.cpp:97-98
> + // Argument can be split into multiple discontiguous pieces, for example:
> + // "Hello " "World"
> + // this would result in a single argument "Hell
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
This looks correct to me. I had a couple of trivial inline comments, but this
looks fine.
> BreakpointID.cpp:80-81
>
> -bool BreakpointID::ParseCanonicalReference(const char *input,
> +
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
No good deed goes unpunished... You made ParseCanonicalReference more
beautiful but forgot to update the header doc.
Also I didn't see the comment for SplitIDRangeExpression.
>
Ah, missed it there. No it is fine to put it in the header.
Jim
> On Oct 4, 2016, at 2:37 PM, Zachary Turner wrote:
>
> zturner added inline comments.
>
>
>> jingham wrote in BreakpointIDList.cpp:329-330
>> Did you upload the latest version of your patch, I don't see a comment
>> here...
>
Author: jingham
Date: Tue Oct 4 19:07:01 2016
New Revision: 283276
URL: http://llvm.org/viewvc/llvm-project?rev=283276&view=rev
Log:
Add the new minidump files to the Xcode project.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
Author: jingham
Date: Tue Oct 4 20:09:43 2016
New Revision: 283287
URL: http://llvm.org/viewvc/llvm-project?rev=283287&view=rev
Log:
This test is failing because there's a global symbol "C" in libsystem_c.dylib,
and that is defeating the lookup of the "struct C" here. Adding the bug for
that.
Author: jingham
Date: Tue Oct 4 20:19:15 2016
New Revision: 283289
URL: http://llvm.org/viewvc/llvm-project?rev=283289&view=rev
Log:
The collision of class C and libsystem_c.dylib:C is a failure
worth preserving, but not essential to the purpose of this test
so I broke it into a separate test.
M
> On Dec 11, 2015, at 2:42 PM, Zachary Turner wrote:
>
> Yes, but as I mentioned, two things are still unsupported due to limitations
> in clang-format. They are return-type-on-new-line (only in declarations.
> clang-format supports it for definitions) and the constructor initializer
> list
Note, it is pure speculation that this is a bug in clang-format based on where
the : is placed.
I prefer the way we write it, because it places all the initializers on the
same level, though I don’t feel so strongly about this one.
I would really rather not go through making wholesale changes l
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
That looks fine.
http://reviews.llvm.org/D15407
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman
I see the value of replacing NULL with nullptr, but I don't see the value of
these sorts of changes:
> On Dec 14, 2015, at 5:33 PM, Eugene Zelenko via lldb-commits
> wrote:
>
> @@ -118,19 +111,13 @@ ThreadPlanStepInstruction::IsPlanStale (
> StackID cur_frame_id = m_thread.GetStackFrameAtI
I think Jason already did (r255597).
Jim
> On Dec 14, 2015, at 6:35 PM, Siva Chandra via lldb-commits
> wrote:
>
> On Mon, Dec 14, 2015 at 4:50 PM, Kamil Rytarowski via lldb-commits
> wrote:
>> Author: kamil
>> Date: Mon Dec 14 18:50:19 2015
>> New Revision: 255592
>>
>> Added:
>>lldb/tr
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
That's great.
Repository:
rL LLVM
http://reviews.llvm.org/D15326
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm
We don't indent access modifiers, so if AccessModifierOffset does what it's
name suggests, then that's right.
Jim
> On Dec 16, 2015, at 8:09 AM, Todd Fiala wrote:
>
> tfiala added a reviewer: jingham.
> tfiala added a comment.
>
> Hey Jim, this looks right to me. Agree?
>
> -Todd
>
>
> ht
jingham added a subscriber: jingham.
jingham added a comment.
We don't indent access modifiers, so if AccessModifierOffset does what it's
name suggests, then that's right.
Jim
http://reviews.llvm.org/D15562
___
lldb-commits mailing list
lldb-commi
jingham added a subscriber: jingham.
jingham requested changes to this revision.
jingham added a reviewer: jingham.
jingham added a comment.
This revision now requires changes to proceed.
I don't think this is sufficiently different from "target modules dump
line-tables" to warrant a separate com
jingham added a comment.
Okay. So it seems like there are a couple of orthogonal differences here.
1. The current behavior requires that the the source file you pass in be a
compile unit. We don't search inside the line tables. So for instance
target modules dump line-tables foo.h
would cur
jingham added a comment.
Provided we error out appropriately I don't think we need to support all
possible combinations of options. I'd happier doing it by options and not
supporting the combinations that aren't worth the effort. Then if anybody
really needs one of the unsupported ones, the p
jingham added a comment.
That seems fine for now.
Note, if you use the OptionGroupOptions way of defining the new options for
your command, then you can call OptionsSeen to tell you which options were
actually provided by the user, so for extra credit, if --compile-unit-only is
true and no oth
That seems fine for now.
Note, if you use the OptionGroupOptions way of defining the new options for
your command, then you can call OptionsSeen to tell you which options were
actually provided by the user, so for extra credit, if --compile-unit-only is
true and no other options were provided
> On Dec 17, 2015, at 10:25 AM, Dawn Perchik wrote:
>
> dawn marked 6 inline comments as done.
> dawn added a comment.
>
>> clang-format your changes please (there are many deviations from the coding
>> style)
>
>
> I've made some fixes even though the code is no longer consistent with the
Author: jingham
Date: Thu Dec 17 20:14:04 2015
New Revision: 255972
URL: http://llvm.org/viewvc/llvm-project?rev=255972&view=rev
Log:
Make the Language print the description of the Exception Breakpoint resolver.
Also
have the breakpoint description print the precondition description if one
exis
Author: jingham
Date: Thu Dec 17 20:15:25 2015
New Revision: 255973
URL: http://llvm.org/viewvc/llvm-project?rev=255973&view=rev
Log:
Fix formatting for last commit.
Modified:
lldb/trunk/source/Target/Language.cpp
Modified: lldb/trunk/source/Target/Language.cpp
URL:
http://llvm.org/viewvc/l
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
I don't so much mind that you couldn't reuse
AdvanceAddressToNextBranchInstruction, we wouldn't be using the "get the
disassembly" part of it, which is the biggest bit, since that'
jingham added a subscriber: jingham.
jingham added a comment.
Shouldn't we just remove the Linux test case in favor of your test case? The
notion of a builtin_trap of some sort or other seems general. And, it looks
like both the Linux port and the Windows port needed to do something to handle
jingham added a comment.
Can you post the backtrace in this case? It seems to me odd that CanJIT ->
AllocateMemory needs to construct the AppleObjCRuntime to do its job. I'd
rather cut the chain at that point if it makes sense.
http://reviews.llvm.org/D15978
__
Author: jingham
Date: Thu Jan 7 18:20:47 2016
New Revision: 257120
URL: http://llvm.org/viewvc/llvm-project?rev=257120&view=rev
Log:
Fix a glitch in the Driver's batch mode when used with "attach".
Batch mode is supposed to stop execution and return control to the user when an
exceptional stop
jingham added a comment.
Ah, right. We're doing that so that we can make sure that an ObjC Exception
thrown during the course of expression evaluation doesn't unwind past the frame
we are using to call the function.
Seems like for low-level stuff like AllocateMemory we should be avoiding all
jingham added a comment.
That penultimate sentence would be clearer if I had put the end ")" in the
right place - after "recursion"
http://reviews.llvm.org/D15978
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-b
jingham added a comment.
Cool! For completeness I think it is a good idea to do this to all the
functions in InferiorCallPOSIX. For the general InferiorCall one it might be a
good idea to add a defaulted (to false) parameter so that if somebody really
needs to use it for something that might
jingham added a subscriber: jingham.
jingham added a comment.
Would you mind adding a note to README-TestSuite saying that you have to call
this function if you want to attach to the binary you are building as part of
the testsuite. As with all docs it's likely very few will read the note, but
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Thanks for adding this, are you able to check it in? Otherwise I will.
http://reviews.llvm.org/D15684
___
lldb-commits mailing list
lldb-commi
jingham added a comment.
If you don't mind, please add the same code to the InferiorCallMunmap, and then
add the same thing to InferiorCall, but that's the one that should take a
parameter in case somebody does end up using the general function for something
that could throw. Otherwise we'll j
jingham accepted this revision.
jingham added a comment.
Great, thanks!
http://reviews.llvm.org/D15978
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: jingham
Date: Fri Jan 8 17:44:51 2016
New Revision: 257234
URL: http://llvm.org/viewvc/llvm-project?rev=257234&view=rev
Log:
Fix a thinko in the asserts in GetDynamicTypeAndAddress. It was requiring that
the
process in the incoming value be non-null, but Value Objects created off the
t
Author: jingham
Date: Fri Jan 8 18:08:16 2016
New Revision: 257235
URL: http://llvm.org/viewvc/llvm-project?rev=257235&view=rev
Log:
Fiddling with Pavel's fix for getting the breakpoint right when there's debug
info for sleep.
I prefer to use "-p" over using line_number and then setting by line
I think it's actually C99 rules, but...
Jim
> On Jan 8, 2016, at 3:25 PM, Adrian McCarthy via lldb-commits
> wrote:
>
> Oops! Thanks for the fix. I'd tested only with clang, which seems to apply
> C++ rules even with .c files.
>
> I'm curious why I didn't see this break on any of the build
Author: jingham
Date: Fri Jan 8 19:20:30 2016
New Revision: 257242
URL: http://llvm.org/viewvc/llvm-project?rev=257242&view=rev
Log:
Writing a test case for r257234 I found another place that was
assuming a ValueObject always has a process. So this is that fix
and the test case.
Added:
lldb
I worry giving up on testing using Python's stdout for the immediate output
stream. This is a very useful feature, allowing users to make Python based
commands that produce a bunch of output, and stream the output as it is being
gathered rather than having the command stall and then dump a bunc
Yes, on unix all things are files and all files work the same except when they
don't. I'd rather test the thing we ACTUALLY care about, rather than testing
something else and assuming that it is going to work in the case we care about
as well.
Jim
> On Jan 14, 2016, at 10:58 AM, Zachary Turne
Well, actually on Unix MOST things are files, it was Plan 9 in which that all
things are files, IIRC...
Jim
> On Jan 14, 2016, at 11:04 AM, Jim Ingham wrote:
>
> Yes, on unix all things are files and all files work the same except when
> they don't. I'd rather test the thing we ACTUALLY care
Author: jingham
Date: Thu Jan 14 19:03:50 2016
New Revision: 257852
URL: http://llvm.org/viewvc/llvm-project?rev=257852&view=rev
Log:
The ASAN report fetching code had two latent bugs:
1) It was forward declaring functions without 'extern "C"'. That used to work
but only because of another bug
jingham added a comment.
Yes, that is a cleaner way to do this.
In about half the cases you use get_threads_stopped_at_breakpoint and half
get_stopped_thread. It looks like you were just mirroring what the test did,
so that's fine, but if I know the breakpoint I'm expecting, I prefer
get_thre
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
Oh, yeah, I'm supposed to say "request changes" for the use of
get_threads_stopped_at_breakpoint...
http://reviews.llvm.org/D16247
_
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
That looks good. get_one_thread_stopped_at_breakpoint is convenient, but I'd
rather not sweep under the rug cases where you expected only one thread to hit
your breakpoint but mor
jingham added a comment.
That would be fine too. Just seems like this is asking to have a miswritten
test that accidentally stops at two hits of the breakpoint but you didn't
notice because MOST of the time, the right thread was first, which would lead
to an odd flakey test.
http://reviews.l
jingham added a subscriber: jingham.
jingham added a comment.
I agree with Zachary. Just because a test found a bug that wasn't essential to
the test doesn't mean we should "fix" the test by silencing the part of the
test that uncovered the bug.
This test puts a breakpoint on a 'puts("")' stat
I sort of agree with this and sort of don't. Formally, I agree with the notion
of limited focused tests. But in practice it is often the noise in tests that
catches bugs that we don't yet have tests for. And especially when the "noise"
is doing things like step over that 100% should work in a
jingham added a comment.
I sort of agree with this and sort of don't. Formally, I agree with the notion
of limited focused tests. But in practice it is often the noise in tests that
catches bugs that we don't yet have tests for. And especially when the "noise"
is doing things like step over
> On Jan 20, 2016, at 11:25 AM, Zachary Turner wrote:
>
> zturner added a comment.
>
> For example, what if someone adds a test that uses a very small amount of
> functionality but tests the thing it's supposed to test. Do we block the
> change and say "please make this test more complicated
> On Jan 21, 2016, at 10:17 AM, Zachary Turner wrote:
>
> zturner added a comment.
>
> Sure, an interface change to Process might break the mock, but it would break
> at compile time, you just fix it up. It's not something that would happen
> frequently, this is the same situation going on i
I'm not sure this is a terribly productive discussion.
Since I know that the debugger is stateful, when I write a test where I get to
point A and do thing X, I will often add - while I'm there - "step again and
see if it still works" or something morally equivalent to that. I have found
that
Would you mind adding a comment telling people how to do this correctly to the
"Writing test cases" section of the README-testsuite?
Jim
> On Jan 22, 2016, at 3:54 PM, Zachary Turner via lldb-commits
> wrote:
>
> Author: zturner
> Date: Fri Jan 22 17:54:41 2016
> New Revision: 258586
>
> URL
That would be fine as an additional test.
There isn't an SBThread::SetName, but that would be trivial to add.
Also, if we are going to rely on this, we should improve how SetName is done.
Right now the default implementation does nothing, so it relies on the
particular implementation to se
> On Jan 27, 2016, at 8:25 AM, Enrico Granata via lldb-commits
> wrote:
>
> granata.enrico added a comment.
>
> It looks like this code is default constructing a SBExpressionOptions(),
> which at the end of the day is a fancy wrapper for EvaluateExpressionOptions
>
> This last object gets de
> On Jan 27, 2016, at 9:20 AM, Jim Ingham via lldb-commits
> wrote:
>
>
>> On Jan 27, 2016, at 8:25 AM, Enrico Granata via lldb-commits
>> wrote:
>>
>> granata.enrico added a comment.
>>
>> It looks like this code is default constructing
601 - 700 of 1210 matches
Mail list logo
