We’ve had many instances of flakiness in non pexpect tests (on all
platforms). There’s no obvious pattern to when a test will be flaky.
Whether those are due to dotest or liblldb is an open question, but one
good way of answering those types of questions is to replace one source of
unknown-flakines
Also, I can think of at least 3 different companies/people who are
investing in LLDB for their downstream needs (who haven't publicly
announced this, so this isn't widely known), which involves bringing LLDB
up on currently unsupported platforms. It's easy to lose sight of what
that entails when y
On Mon, Jan 29, 2018 at 6:11 PM Jim Ingham wrote:
>
> The wider LLVM community tests a very different kind of tool than lldb,
> which leaves me less moved by the argumentum ad verecundiam than I might
> otherwise be.
>
But it's not a different kind of test than this particular test, which is
why
Yea good point. We can probably punt on this for now as it’s just a
nice-to-have
On Thu, Feb 1, 2018 at 1:38 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added inline comments.
>
>
>
> Comment at: lit/SymbolFile/PDB/func-symbols.test:4
> +RUN: clang-
Same reason that people use perl for heavy text processing, R for
scientific programming, python for rapid iteration. It’s what they’re built
for. When something is built for a very focused specific problem domain,
the problems in that domain can be expressed very concisely and naturally.
In the c
Also, failures that are easy to reproduce are easy to debug. When a test
fails this way, you get a command line that can reproduce the problem that
can be debugged directly without having to debug across the python
boundary. I find that very helpful personally
On Wed, Feb 7, 2018 at 5:48 PM Zachary
Yes but debugging across several api calls is annoying, and the command
line in the log file doesn’t ever work for me
On Wed, Feb 7, 2018 at 6:07 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> If a dotest test fails, you go to the Failure-whatever.l
Looks good. Stuff like this feel free to just commit
On Wed, Feb 7, 2018 at 7:53 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith created this revision.
> asmith added reviewers: zturner, lldb-commits.
> Herald added a subscriber: llvm-commits.
>
> LLDB_TEST_COMPILER is n
I think just remove the preprocessor block. Imagine debugging a Windows
target from a linux host. This function would return false as written
because the host wasn’t Windows
On Thu, Feb 8, 2018 at 12:18 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith added a comment.
>
>
Looks good (but for the _Z case, make sure its length is at least 2)
On Thu, Feb 8, 2018 at 12:33 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith added a comment.
>
> How about this?
>
> if (name == nullptr)
> return false;
>
> return ( (name[0] == '?') || (name[
The problem is that CMAKE_CFG_INTDIR evaluates to something very common,
like “Debug” or “Release”, and replacing a common string like that in a
path creates more problems than it solves in my opinion. What if your build
dir is C:\src\LLDBDebugger\out\Debug\clang.exe? Debug appears twice in this
st
If the default is already to use the just built clang, and an explicit path
allows you to override this, then do we need any switch at all? If the
problem is that the default doesn’t correctly handle visual studio
generator, maybe we could fix that instead?
On Thu, Feb 8, 2018 at 9:43 PM Stiliyana
On Fri, Feb 9, 2018 at 12:19 PM Stiliyana Stamenova <
stiliyana.stamen...@gmail.com> wrote:
> No, we don't need a switch unless we want to be explicit.
>
> I am not sure what you mean by "fix that instead" - the VS generator?
>
What I meant is that if the default behavior (i.e. LLDB_TEST_C_COMPILE
On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote:
>
>
> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > zturner added a comment.
> >
> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> >
> > I don't think we'd nece
Sure I don’t think anyone disputes that, but I thought we were discussing
an ideal end state
On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda wrote:
>
>
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote:
> >
> >
> >
> > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda
> wrote:
> >>
> >>
> >> >
No
On Wed, Feb 14, 2018 at 2:46 PM Adrian McCarthy via Phabricator <
revi...@reviews.llvm.org> wrote:
> amccarth added a comment.
>
> Any remaining concerns?
>
>
> https://reviews.llvm.org/D43215
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.l
I wouldn’t use std::bind though, just make a lambda.
On Thu, Feb 22, 2018 at 6:06 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.org/D43662#1016939, @vsk wrote:
>
> > > What do you think about a syntax like:
> > >
> > > lldb
Llvm also separates the Integration tests (test-suite) from the regression
tests. That’s another approach to handling the Cartesian product testing
On Mon, Feb 26, 2018 at 6:01 PM Paul Robinson via Phabricator via
lldb-commits wrote:
> probinson added a comment.
>
> In https://reviews.llvm.org/D3
What about having the macro do the log printing in a function so you can
put the breakpoint in the function?
On Wed, Feb 28, 2018 at 5:56 PM Vedant Kumar via Phabricator <
revi...@reviews.llvm.org> wrote:
> vsk added inline comments.
>
>
>
> Comment at: include/lldb/Utility/Log.h:
Lgtm
On Tue, Mar 6, 2018 at 9:14 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith updated this revision to Diff 137324.
> asmith added a comment.
>
> Add test
>
>
> https://reviews.llvm.org/D44166
>
> Files:
> lit/SymbolFile/PDB/Inputs/SimpleTypesTest.cpp
> lit/Symbol
Shouldn’t it be lldb-dotest? I’m confused about what this target does
On Wed, Mar 14, 2018 at 8:21 AM Davide Italiano via Phabricator <
revi...@reviews.llvm.org> wrote:
> davide accepted this revision.
> davide added a comment.
> This revision is now accepted and ready to land.
>
> LGTM
>
>
> Repo
I think having all parsing functions in a single place will just move the
layering problem elsewhere, since a bunch of conversion functions for
objects from various libraries will be mushed together into one place.
On Wed, Mar 14, 2018 at 11:34 AM Jim Ingham via Phabricator <
revi...@reviews.llvm.
I haven’t had time to look at this in detail yet, but when I originally had
this idea I thought we would use lit’s discovery mechanism to find all .py
files, and then invoke them using dotest.py in single process mode with a
path to a specific file.
Why do we need run lines?
On Wed, Apr 4, 2018 at
On Wed, Apr 4, 2018 at 8:11 AM Jonas Devlieghere via Phabricator <
revi...@reviews.llvm.org> wrote:
> JDevlieghere added a comment.
>
> In https://reviews.llvm.org/D45215#1056917, @zturner wrote:
>
> > I haven’t had time to look at this in detail yet, but when I originally
> had
> > this idea I t
Sure, but getting lit to run one file at a time is a nice incremental step
towards that and can make both patches easier to review.
On Wed, Apr 4, 2018 at 9:02 AM Adrian Prantl wrote:
>
> On Apr 4, 2018, at 8:53 AM, Pavel Labath wrote:
>
>
>
> On Wed, 4 Apr 2018 at 16:47, Zachary Turner wrote:
I have some ideas for how to run the different variants as separate tests,
but I'll save it for the next RFC :)
On Wed, Apr 4, 2018 at 10:24 AM Jonas Devlieghere
wrote:
>
> > On Apr 4, 2018, at 5:12 PM, Adrian Prantl wrote:
> >
> >
> >
> >> On Apr 4, 2018, at 9:07 AM, Zachary Turner wrote:
> >
I think you need to mark this inline otherwise you're going to get multiple
definitions no?
On Mon, Apr 16, 2018 at 11:29 AM Davide Italiano via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: davide
> Date: Mon Apr 16 11:25:57 2018
> New Revision: 330147
>
> URL: http://llvm.org/vie
Well let’s see what Davide and Adrian think. I’m more of an outsider these
days so consider my perspective an llvm-centric one, which would sometimes
(but not always) be the best for lldb
On Wed, Apr 25, 2018 at 12:31 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath adde
But is there a reason why that is more valuable with LLDB than it is with
LLVM? In LLVM when a test fails it stops and doesn't run subsequent run
lines. So you have the same issue there. The way this is handled in LLVM
is that if you think tests are sufficiently different that they could be
brok
Sure multiple run lines can be commands being executed that depend on each
other, but it's very common for a test to have multiple check labels as well
On Wed, Apr 25, 2018 at 9:19 AM Adrian Prantl wrote:
>
> On Apr 25, 2018, at 9:08 AM, Zachary Turner wrote:
>
> But is there a reason why that
On Wed, Apr 25, 2018 at 9:19 AM Adrian Prantl wrote:
>
> On Apr 25, 2018, at 9:08 AM, Zachary Turner wrote:
>
> But is there a reason why that is more valuable with LLDB than it is with
> LLVM? In LLVM when a test fails it stops and doesn't run subsequent run
> lines. So you have the same issu
Author: zturner
Date: Fri Mar 17 11:32:43 2017
New Revision: 298099
URL: http://llvm.org/viewvc/llvm-project?rev=298099&view=rev
Log:
Fix some signed/unsigned comparison warnings.
Patch by Hugh Bellamy
Differential Revision: https://reviews.llvm.org/D30926
Modified:
lldb/trunk/source/Core/Fo
Author: zturner
Date: Fri Mar 17 11:33:37 2017
New Revision: 298100
URL: http://llvm.org/viewvc/llvm-project?rev=298100&view=rev
Log:
CMake requires normalized paths when appending.
Patch by Hugh Bellamy
Differential Revision: https://reviews.llvm.org/D30927
Modified:
lldb/trunk/cmake/module
Author: zturner
Date: Sun Mar 19 00:48:01 2017
New Revision: 298202
URL: http://llvm.org/viewvc/llvm-project?rev=298202&view=rev
Log:
Fix unit test compilation failure.
Modified:
lldb/trunk/unittests/Interpreter/TestCompletion.cpp
Modified: lldb/trunk/unittests/Interpreter/TestCompletion.cpp
Author: zturner
Date: Sun Mar 19 00:48:47 2017
New Revision: 298203
URL: http://llvm.org/viewvc/llvm-project?rev=298203&view=rev
Log:
Remove FileSystem::MakeDirectory.
Have callers use llvm::sys::fs::create_directory() instead.
Differential Revision: https://reviews.llvm.org/D31086
Modified:
Author: zturner
Date: Sun Mar 19 00:49:43 2017
New Revision: 298205
URL: http://llvm.org/viewvc/llvm-project?rev=298205&view=rev
Log:
Remove FileSystem::Get/SetFilePermissions
Differential Revision: https://reviews.llvm.org/D31089
Modified:
lldb/trunk/include/lldb/Host/FileSystem.h
lldb/
Author: zturner
Date: Sun Mar 19 01:00:31 2017
New Revision: 298206
URL: http://llvm.org/viewvc/llvm-project?rev=298206&view=rev
Log:
Fix syntax error when building with editline support.
Modified:
lldb/trunk/source/Host/common/Editline.cpp
Modified: lldb/trunk/source/Host/common/Editline.cp
The reason was because two different tests from two different unittest
executables need it, but we have no good way to share code across unittests
like this. Open to suggestions though
On Mon, Mar 20, 2017 at 4:02 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added in
I thought about something like that too. Let me try to get all these other
patches landed first then I'll think about what to do.
On Mon, Mar 20, 2017 at 9:25 AM Pavel Labath wrote:
> Aha, I see that now. What do you think about creating a test-only module
> that both unit tests can depend on?
Author: zturner
Date: Mon Mar 20 18:33:18 2017
New Revision: 298322
URL: http://llvm.org/viewvc/llvm-project?rev=298322&view=rev
Log:
Add a function to MD5 a file's contents.
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but fo
Author: zturner
Date: Mon Mar 20 18:54:26 2017
New Revision: 298324
URL: http://llvm.org/viewvc/llvm-project?rev=298324&view=rev
Log:
[analyze-project-deps.py] Add the ability to list all cycles.
This analyzes the dependency graph and computes all minimal
cycles. Equivalent cycles that differ on
Author: zturner
Date: Mon Mar 20 18:54:54 2017
New Revision: 298325
URL: http://llvm.org/viewvc/llvm-project?rev=298325&view=rev
Log:
Delete LLDB's MD5 code. Use LLVM instead.
Differential Revision: https://reviews.llvm.org/D31108
Modified:
lldb/trunk/include/lldb/Host/FileSystem.h
lldb/
Author: zturner
Date: Mon Mar 20 18:55:20 2017
New Revision: 298326
URL: http://llvm.org/viewvc/llvm-project?rev=298326&view=rev
Log:
[Support] Fill the file_status struct with link count.
Differential Revision: https://reviews.llvm.org/D31110
Modified:
lldb/trunk/source/Host/common/File.cpp
Author: zturner
Date: Mon Mar 20 23:01:04 2017
New Revision: 298334
URL: http://llvm.org/viewvc/llvm-project?rev=298334&view=rev
Log:
Delete various lldb FileSystem functions.
Use LLVM's equivalent versions instead.
Differential Revision: https://reviews.llvm.org/D3
Modified:
lldb/trunk
Author: zturner
Date: Mon Mar 20 23:01:59 2017
New Revision: 298335
URL: http://llvm.org/viewvc/llvm-project?rev=298335&view=rev
Log:
Delete some dead code in HostInfo.
Modified:
lldb/trunk/include/lldb/Host/HostInfoBase.h
lldb/trunk/include/lldb/Host/freebsd/HostInfoFreeBSD.h
lldb/tr
Author: zturner
Date: Tue Mar 21 00:47:57 2017
New Revision: 298340
URL: http://llvm.org/viewvc/llvm-project?rev=298340&view=rev
Log:
Resubmit r298334 after fixing OSX build errors.
Hopefully this works, I can't test since I don't have Mac
hardware, however.
Modified:
lldb/trunk/include/lldb
I found it, but in the future would you mind including a link to the
buildbot?
On Mon, Mar 20, 2017 at 9:57 PM Jason Molenda via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: jmolenda
> Date: Mon Mar 20 23:45:10 2017
> New Revision: 298338
>
> URL: http://llvm.org/viewvc/llvm-proje
Thanks for the suggestions! Not sure if I'll be able to make those changes
before tomorrow EOD, and after that I will be out for ~2 weeks, so if time
doesn't permit, I may not follow up with another patch until after I get
back.
On Tue, Mar 21, 2017 at 11:19 AM Jim Ingham via Phabricator <
revi..
Author: zturner
Date: Tue Mar 21 13:25:04 2017
New Revision: 298412
URL: http://llvm.org/viewvc/llvm-project?rev=298412&view=rev
Log:
Move StringList from Core -> Utility.
Added:
lldb/trunk/include/lldb/Utility/StringList.h
lldb/trunk/source/Utility/StringList.cpp
Removed:
lldb/trunk/
Author: zturner
Date: Tue Mar 21 13:45:42 2017
New Revision: 298419
URL: http://llvm.org/viewvc/llvm-project?rev=298419&view=rev
Log:
Fix build broken by StringList move.
Modified:
lldb/trunk/include/lldb/Utility/StringList.h
lldb/trunk/source/Symbol/Symtab.cpp
Modified: lldb/trunk/inclu
Author: zturner
Date: Tue Mar 21 17:46:46 2017
New Revision: 298455
URL: http://llvm.org/viewvc/llvm-project?rev=298455&view=rev
Log:
[deps script] Sort cycles by the difficulty of breaking.
When passing --discover-cycles and --show-counts, it displays
the number of dependencies between each hop
Author: zturner
Date: Tue Mar 21 19:27:24 2017
New Revision: 298465
URL: http://llvm.org/viewvc/llvm-project?rev=298465&view=rev
Log:
Delete the remainder of platform specific code in FileSpec.
Differential Revision: https://reviews.llvm.org/D31129
Added:
lldb/trunk/unittests/Utility/Mocks/
Author: zturner
Date: Tue Mar 21 19:27:54 2017
New Revision: 298466
URL: http://llvm.org/viewvc/llvm-project?rev=298466&view=rev
Log:
Break the cycle between Host and PluginProcessUtility.
There are only two users of NativeRegisterContextRegisterInfo,
and both are in process plugins. Moving this
Author: zturner
Date: Wed Mar 22 12:08:25 2017
New Revision: 298519
URL: http://llvm.org/viewvc/llvm-project?rev=298519&view=rev
Log:
Delete TestLLVM.py
This was added to workaround a limitation in LLVM's implementation
of getting the current user's home directory, since it would
only look at the
Author: zturner
Date: Wed Mar 22 12:33:23 2017
New Revision: 298526
URL: http://llvm.org/viewvc/llvm-project?rev=298526&view=rev
Log:
Resubmit "Delete the remainder of platform specific code in FileSpec."
This was causing a test failure in one of LLDB's tests which
specifically dealt with a limit
Author: zturner
Date: Wed Mar 22 13:04:20 2017
New Revision: 298530
URL: http://llvm.org/viewvc/llvm-project?rev=298530&view=rev
Log:
[analyze deps] Also show cycle islands.
We currently display a list of all minimal cycles, but it's
useful to be able to see the big picture impact of these cycles
Author: zturner
Date: Wed Mar 22 13:23:14 2017
New Revision: 298535
URL: http://llvm.org/viewvc/llvm-project?rev=298535&view=rev
Log:
[analyze deps] Show incoming and outgoing counts on island members.
Modified:
lldb/trunk/scripts/analyze-project-deps.py
Modified: lldb/trunk/scripts/analyze-
Author: zturner
Date: Wed Mar 22 14:24:17 2017
New Revision: 298541
URL: http://llvm.org/viewvc/llvm-project?rev=298541&view=rev
Log:
Remove dead include from GoASTContext.cpp.
This #include was the cause of a dependency from Symbol ->
DataFormatters. However, nothing from the header was being
u
Author: zturner
Date: Wed Mar 22 18:33:16 2017
New Revision: 298561
URL: http://llvm.org/viewvc/llvm-project?rev=298561&view=rev
Log:
Delete some more dead includes.
This breaks the cycle between Target and PluginLanguageC++, reducing
the overall cycle count from 43 to 42.
Modified:
lldb/tru
I'm ooo for ~2 weeks so I can't really do code reviews unfortunately
On Sat, Mar 25, 2017 at 6:23 AM Chris Bieneman via Phabricator <
revi...@reviews.llvm.org> wrote:
> beanz added a comment.
>
> Xcode is pretty magic to me. I don't know how to do much of anything in it
> other than build. I think
Author: zturner
Date: Thu Apr 6 13:12:24 2017
New Revision: 299676
URL: http://llvm.org/viewvc/llvm-project?rev=299676&view=rev
Log:
iwyu fixes on lldbUtility.
This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). T
Author: zturner
Date: Thu Apr 6 15:51:22 2017
New Revision: 299705
URL: http://llvm.org/viewvc/llvm-project?rev=299705&view=rev
Log:
Try to fix FreeBSD build after iwyu changes.
Modified:
lldb/trunk/source/Host/freebsd/HostInfoFreeBSD.cpp
Modified: lldb/trunk/source/Host/freebsd/HostInfoFre
Author: zturner
Date: Thu Apr 6 16:57:39 2017
New Revision: 299718
URL: http://llvm.org/viewvc/llvm-project?rev=299718&view=rev
Log:
Fix build failure in unit test.
Modified:
lldb/trunk/unittests/Core/BroadcasterTest.cpp
Modified: lldb/trunk/unittests/Core/BroadcasterTest.cpp
URL:
http://l
Author: zturner
Date: Thu Apr 6 17:18:59 2017
New Revision: 299719
URL: http://llvm.org/viewvc/llvm-project?rev=299719&view=rev
Log:
Try to fix FreeBSD build after IWYU changes.
Modified:
lldb/trunk/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
Modified: lldb/trunk/source/Plugins/Proces
Agreed. Before I clang-formatted it, it looked fine, because each
definition was on a single line. But clang-format made them 3 lines each.
So yea, we should definitely merge them. I was copy/pasting the output
from IWYU, which is why it looks this way. Thanks for bringing it up
On Thu, Apr 6,
Lgtm
On Mon, Apr 10, 2017 at 11:03 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> labath created this revision.
> Herald added a subscriber: mgorny.
>
> The files there can always be referred to using their full path, which
> is what most of the code has been doing already, so this mak
Just to be clear, this patch was only intended to be a starting point. I
didn't run the test suite or do anything other than verify that the core
loaded. ArchSpec is a pretty core class so touching it in this manner is
likely to have many side effects that you'll need to work out.
Most likely so m
ure
> exactly which it might be.
>
> If this can't be tested through the unit test framework, it would be easy
> to add an SB API test case, see above.
>
> Thanks
>
>
>
> > On Mar 12, 2017, at 11:18 AM, Zachary Turner via lldb-commits <
> lldb-commits@li
Author: zturner
Date: Fri Apr 14 21:44:53 2017
New Revision: 300386
URL: http://llvm.org/viewvc/llvm-project?rev=300386&view=rev
Log:
Fix crash when completing in the current directory.
Modified:
lldb/trunk/source/Commands/CommandCompletions.cpp
lldb/trunk/unittests/Interpreter/TestComple
; file /Volumes/newwork/svn/lldb/source/Commands/CommandCompletions.cpp, line
>> 179.
>> Abort
>>
>>
>> maybe it's related from r297585? There have been a few overlapping
>> changes to CommandCompletions.cpp by you and Pavel recently, not sure
>> exactly which
Does 0 mean infinite here? If so are the newly introduced semantics here
still correct?
On Sat, Apr 15, 2017 at 3:34 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> labath accepted this revision.
> labath added a comment.
> This revision is now accepted and ready to land.
>
> looks good
We already have this exact code in lldb/cmake/LLDBConfig.txt. This fix
looks fine, but I see no reason to have it twice, so can you delete the
LLDB version?
On Mon, Apr 17, 2017 at 7:01 AM Kamil Rytarowski via Phabricator <
revi...@reviews.llvm.org> wrote:
> krytarowski added a comment.
>
> Is t
Note that getAsInteger returns false on success, so be careful!
On Thu, Apr 20, 2017 at 6:09 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.org/D32149#731920, @krytarowski wrote:
>
> > In https://reviews.llvm.org/D32149#7318
On Thu, Apr 20, 2017 at 9:00 PM Greg Clayton via Phabricator via
lldb-commits wrote:
> clayborg requested changes to this revision.
> clayborg added a comment.
> This revision now requires changes to proceed.
>
> Very close. A few misuses of ConstString and this will be good to go.
>
>
>
> ==
Which C compilers do we have that are not capable of producing ELF
binaries? GCC on Windows maybe? That's not even a supported test
configuration.
On Mon, Apr 24, 2017 at 2:29 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.ll
We don't support running the test suite on Windows with MSVC. We run it
with clang targeting windows instead. So anyone running the test suite on
Windows is already using clang, and we can just specify a linux triple to
get an ELF binary.
On Mon, Apr 24, 2017 at 2:47 PM Eugene Zemtsov wrote:
>
I suppose that's a reasonable concern. I also didn't notice that this was
a unittest, I assumed it was a lit test.
If that's the case, is there any way to use llvm/Object to construct a
minimal ELF file in memory with a hardcoded symbol in the BSS section. It
can even be missing certain critical
Other alternatives though include adding a function to StringMap which
gives us what we need, and having this function do the pointer hacking, or
simply calling strlen.
On Wed, Apr 26, 2017 at 11:03 AM Scott Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> scott.smith added inline comme
There is a file in the repo called git-clang-format. Make sure that file
is on your PATH somewhere, then just run `git clang-format`. It will only
touch lines that are part of your diff, and leave surrounding lines alone.
When making a diff, we only want to clang-format the lines we touched, not
In case it's not obvious, note the space in the command I said to run.
`git-clang-format` has a dash, and when you run `git clang-format` (with a
space), it will run the file with the dash.
On Thu, Apr 27, 2017 at 8:58 AM Zachary Turner wrote:
> There is a file in the repo called git-clang-form
"(lldb) settings set target.cache-priming foo"
On Thu, Apr 27, 2017 at 11:53 AM Scott Smith via Phabricator via
lldb-commits wrote:
> scott.smith added a comment.
>
> In https://reviews.llvm.org/D32598#739804, @jingham wrote:
>
> > Instead of having the cache priming be determined by platform or
Then make it ready :-/
Why does LLDB need llvm::ThreadPool for this to work? I proposed a single
function that is not dependent on any particular instance of a thread pool.
template
void parallel_for_each(Range &&R, Func &&F) {
// call F(Index, *Iter) for every item in R.
}
std::vector Foos
Can you rewrite the exe path computation to use os.path.join so we're not
assuming posix syntax?
On Tue, May 2, 2017 at 11:11 PM vignesh balu via Phabricator via
lldb-commits wrote:
> vbalu updated this revision to Diff 97550.
> vbalu added a comment.
>
> Corrected the code. Now this test will fa
Don't even need a template. Use llvm::function_ref
On Fri, May 5, 2017 at 4:30 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL302223: Add TaskMap for iterating a function over a set
Take a look at ErrorChecking.h in llvm, it contains some useful macros for
using expected and error
On Mon, May 8, 2017 at 5:42 AM Kamil Rytarowski via Phabricator via
lldb-commits wrote:
> krytarowski added inline comments.
>
>
>
> Comment at: unittests/tools/lldb-server/inferio
Author: zturner
Date: Fri May 12 00:48:54 2017
New Revision: 302874
URL: http://llvm.org/viewvc/llvm-project?rev=302874&view=rev
Log:
Fix Linux Buildbot.
Modified:
lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.cpp
Modified: lldb/trunk/source/Plugins/Process/Linux/SingleStepCheck.cp
Author: zturner
Date: Fri May 12 00:49:54 2017
New Revision: 302875
URL: http://llvm.org/viewvc/llvm-project?rev=302875&view=rev
Log:
Update StructuredData::String to return StringRefs.
It was returning const std::string& which was leading to
unnecessary copies all over the place, and preventing
Yea, I think at best we can just put a doxygen comment above the function
explaining it
On Sat, May 13, 2017 at 11:10 PM Kamil Rytarowski via Phabricator <
revi...@reviews.llvm.org> wrote:
> krytarowski added a comment.
>
> It's not that perfectly clear to me that `SetStatus()` returns
> `Succeede
Indeed, ideally there is no bool return value and we just write return
make_error("foo")
On Mon, May 15, 2017 at 5:58 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> I think this is a step in the right direction. Besides reducing
> boilerplate, this
Even though it creates a different TaskGroup for each one, TaskGroup itself
just says getDefaultExecutor, and that returns a global instance. On
Windows this will work because it all delegates to an OS thing that's sort
of like libdispatch and that does support recursion, but the thread pool
execu
Having the construction accept an Error is probably fine, because you have
to std::move it anyway, which means you know you're giving up ownership
On Wed, May 17, 2017 at 3:08 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.o
Lgtm
On Mon, May 22, 2017 at 6:49 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
>
> A change in swig 3.0.9 has caused it to generate modules incompatible
> with us using them as __init__.py (bug #769). Swig 3.0.11 adds a setting
> to help
> fix
Or just use a std vector
On Fri, May 26, 2017 at 7:00 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added inline comments.
>
>
>
> Comment at:
> source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1304
> + // Allocate the response
I see. In that case, at least store it in a std::unique_ptr.
On Mon, May 29, 2017 at 12:22 AM Ravitheja Addepally via Phabricator <
revi...@reviews.llvm.org> wrote:
> ravitheja added a comment.
>
> Hello, the reason I switched to allocating with new (std::nothrow)
> uint8_t[byte_count]; was beca
Couple of things:
1) Unless you really really want iteration over this map to be in some
deterministic order, better to use unordered_map. And if you do want it to
be in some deterministic order, you should provde a comparison function, as
the default one is probably not what you want.
2) std::ma
DenseSet<> provides a method named find_as which lets you use an arbitrary
type as the lookup key. The only requirement is that your DenseMapInfo<>
that you've specialized provide two methods for each key type you want to
use. So using this approach, even if you have a DenseSet S,
you can still w
Writing tests that are
A) as easy as possible to write and understand
B) built on a multiprocessing infrastructure that is battle tested and
known to not be flaky
C) Familiar to other llvm developers, so as to not discourage subject
matter experts from other areas to make relevant improvements to
This hypothetical DSL could still run SB API statements. I don't
necessarily think it *should*, since what the SB API does and what the
commands do are very different (for example SBTarget.Create() does
something entirely different than "target create", so you're not actually
testing what the debu
And once you start annotating source code with statements, things become
even more concise. For example, you could write the above test:
# input_file: foo.cpp
# int main(int argc, char **argv) { // bp1 = BREAK_HERE
# return 0;// bp2 = BREAK_HERE
# }
# // VERIFY(bp1.hits == 1)
# // VERIFY(
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
301 - 400 of 2276 matches
Mail list logo
