zturner updated this revision to Diff 51090.
zturner added a comment.
Update with context
http://reviews.llvm.org/D18287
Files:
tools/driver/Driver.cpp
tools/driver/Platform.cpp
tools/driver/Platform.h
tools/lldb-mi/CMakeLists.txt
tools/lldb-mi/Platform.cpp
tools/lldb-mi/Platform.h
zturner added inline comments.
Comment at: tools/driver/Driver.cpp:1314
@@ -1313,1 +1313,3 @@
+signal(SIGINT, sigint_handler);
+#ifndef _MSC_VER
signal (SIGPIPE, SIG_IGN);
I think `_MSC_VER` is the right check, because the builtin `signal`
implementation
zturner added a comment.
The reason I mentioned `UNICODE` is because it's one of the main differences
between pre-patch and post-patch. It works for me pre-patch. What command
line are you passing to CMake? Are you using MSVC 2015 Update 1 or initial
release?
The other difference is that I'
zturner created this revision.
zturner added reviewers: amccarth, cameron314.
zturner added a subscriber: lldb-commits.
Windows comes with an extremely limited implementation of `signal` which only
supports a few signal values. Of importance to LLDB is the `SIGINT` value
which invokes a callbac
zturner updated this revision to Diff 50840.
zturner added a comment.
Re-opening this after an update. I had to move `CanCompleteType`,
`CompleteType`, and `LayoutRecordType` implementations into another class
(which I've called `ClangTypeImportHelper`, because PDB needed to use the exact
same
n Mar 18, 2016, at 2:45 PM, Zachary Turner wrote:
>
> Hi Enrico,
>
> These tests are failing on Windows. They're new tests so not really a
> regression, but do you have any idea what might be wrong? Basically, when
> the test runs, the help po is displaying the full outp
Oh yea I think the reason I didn't look at it again is because I was
waiting for the update where you removed the codepage stuff from the driver.
On Thu, Mar 17, 2016 at 11:39 AM Zachary Turner wrote:
> I can look at it today. Sorry again for the delay, rebase 1 more time and
> I&
Author: zturner
Date: Fri Mar 18 17:33:59 2016
New Revision: 263844
URL: http://llvm.org/viewvc/llvm-project?rev=263844&view=rev
Log:
Fix a build issue where the python module could become stale.
We are using hardlinks instead of symlinks, and we attempted to
have some logic where we don't re-cre
zturner added a comment.
Oh yea I think the reason I didn't look at it again is because I was
waiting for the update where you removed the codepage stuff from the driver.
http://reviews.llvm.org/D17107
___
lldb-commits mailing list
lldb-commits@list
zturner added a comment.
I'm not sure what your source tree layout looks like, but this isn't applying
for me. All your paths have "trunk" in front of them, which is a little
unusual in the directory structure is supposed to be something like this:
llvm
tools
lldb
source
A
I'm using the amd64_x86 toolchain. They're supposed to be identical so
that's unlikely to be the problem, but it's the only difference i can see.
Let me know what happens on your clean rebuild
On Fri, Mar 18, 2016 at 7:56 AM Cameron wrote:
> cameron314 added a comment.
>
> Since it works without
Yea, because of the fact that we must support both syntaxes on both
platforms, LLVM library is out.
The whole motivation for introducing the path syntax is so that windows
paths behave as if on Windows even if on linux
On Wed, Mar 16, 2016 at 6:19 AM Pavel Labath wrote:
> labath added inline com
I can look at it today. Sorry again for the delay, rebase 1 more time and
I'll check it out today
On Thu, Mar 17, 2016 at 11:34 AM Cameron wrote:
> cameron314 added a comment.
>
> @zturner: Let me know when you're ready for this patch and I'll rebase it
> again, since there's been quite a few m
zturner added a comment.
I'm using the amd64_x86 toolchain. They're supposed to be identical so
that's unlikely to be the problem, but it's the only difference i can see.
Let me know what happens on your clean rebuild
http://reviews.llvm.org/D17107
zturner added a comment.
I'm getting this when linking:
[826/826] Linking CXX executable bin\lldb.exe
FAILED: cmd.exe /C "cd . && "C:\Program Files (x86)\CMake\bin\cmake.exe" -E
vs_link_exe --intdir=tools\lldb\tools\driver\CMakeFiles\lldb.dir --manifests
-- C:\PROGRA~2\MICROS~3.0\VC\bin\AM
Hi Enrico,
These tests are failing on Windows. They're new tests so not really a
regression, but do you have any idea what might be wrong? Basically, when
the test runs, the help po is displaying the full output of "help
expression". But strangely, if I go into lldb and run "help po" there,
it'
zturner added a comment.
I can look at it today. Sorry again for the delay, rebase 1 more time and
I'll check it out today
http://reviews.llvm.org/D17107
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailma
Author: zturner
Date: Fri Mar 18 18:47:48 2016
New Revision: 263858
URL: http://llvm.org/viewvc/llvm-project?rev=263858&view=rev
Log:
Delete the custom implementation of signal() on Windows.
The Windows SDK provides a version of signal() that is much more
limited compared to other platforms. It
zturner added a comment.
Petr, is this one ok to go in?
http://reviews.llvm.org/D17635
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL263858: Delete the custom implementation of signal() on
Windows. (authored by zturner).
Changed prior to commit:
http://reviews.llvm.org/D18287?vs=51090&id=51093#toc
Repository:
rL LLVM
http://revie
zturner added a comment.
I can remove that comment for you, no worries.
http://reviews.llvm.org/D17635
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Yea that works
On Wed, Mar 16, 2016 at 6:33 AM Pavel Labath wrote:
> labath added a comment.
>
> So I ran the tests on windows (http://reviews.llvm.org/W7 Enterprise) now
> and I did indeed get the long "0:0:...:1" version here instead of "::1".
> Maybe we should just accept both versions as corr
zturner added a comment.
Patch doesn't appear to be clang-formatted. All patches need to be run through
clang-format before submitting.
I think this is my last set of comments. If there's any you disagree with let
me know. If you agree with everything, I can probably just make the changes on
zturner added a comment.
And btw, the multiply defined symbol error is gone now that the custom `signal`
function is removed
http://reviews.llvm.org/D17107
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
zturner added a comment.
ping, any objections here Greg?
http://reviews.llvm.org/D18194
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.
I think this is ready to go in. You probably noticed that this took a long
time to work out all the issues with. In the future if there's any way you
could break things up into smaller pat
Author: zturner
Date: Tue Mar 22 12:58:09 2016
New Revision: 264074
URL: http://llvm.org/viewvc/llvm-project?rev=264074&view=rev
Log:
Unicode support on Win32.
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherev
zturner abandoned this revision.
zturner added a comment.
Abandoning this revision and will re-open a new revision.
http://reviews.llvm.org/D18194
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listin
zturner created this revision.
zturner added a reviewer: clayborg.
zturner added a subscriber: lldb-commits.
This patch attempts to remove the coupling between `ClangASTContext` and DWARF
debug information. Previously, `TypeSystem` exposed a method called
`GetDWARFParser`, which means that any
Should we go back to my original patch then? It left the parser accessible
from TypeSystem, but made it a DebugInfoParser instead of a DWARFParser.
The whole idea is to remove knowledge of a specific debug info format from
the generic TypeSystem, so it still seems wrong to add DWARF specific stuff
zturner added a comment.
I guess my point was just that it seems a little weird to treat DWARF
specially. It's just another debug info format (albeit one that most compilers
support), so by baking into the supposedly generic interface the requirement
that "every type system must be able to sup
zturner updated this revision to Diff 51476.
zturner added a comment.
This patch has gotten both bigger and smaller. Smaller in the sense that after
taking into consideration the most recent comments, there was really only one
piece left of my patch. It is the piece that abstracted out `CanCom
zturner added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1614-1622
@@ -1611,9 +1613,11 @@
TypeSystem *type_system = compiler_type.GetTypeSystem();
-if (type_system)
-{
-DWARFASTParser *dwarf_ast = type_system->GetDWARFPars
zturner updated this revision to Diff 51480.
zturner added a comment.
Fixes issue with `CanCompleteType` being unimplemented. This update deletes
`CanCompleteType` and `CompleteType` from `DWARFASTParser` base class, and
users of that function now call `GetClangASTImporter().CanImport()` and
`
zturner added a comment.
It's been a while since I've used my Mac. I'll fire it up and see if I can get
it going, but no promises. I'll update tomorrow
http://reviews.llvm.org/D18381
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http:
#x27;t know if something has changed.
In any case, let me know if there's something I should be doing.
On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner wrote:
> zturner added a comment.
>
> It's been a while since I've used my Mac. I'll fire it up and see
zturner requested changes to this revision.
zturner added a comment.
This revision now requires changes to proceed.
This patch won't work. `PyFile_AsFile` doesn't exist on Python 3. Anything
that you need done to make this work has to be wrapped up in `PythonFile` class
as it was before, becau
-configuration Debug
>
>
> > On Mar 24, 2016, at 12:31 PM, Zachary Turner wrote:
> >
> > Having trouble building on OSX.
> >
> > ERROR:root:Unable to find swig executable: 'module' object has no
> attribute 'OSError'
> >
> > Co
zturner updated this revision to Diff 51605.
zturner added a comment.
Update patch.
http://reviews.llvm.org/D18381
Files:
include/lldb/Symbol/ClangASTContext.h
include/lldb/Symbol/ClangASTImporter.h
include/lldb/Symbol/ClangUtil.h
include/lldb/Symbol/TypeSystem.h
source/Plugins/Expres
I usually select "desktop" as the target. Is this patch up to date? If so,
> I can apply and compile it and let you know what the results are.
>
> > On Mar 24, 2016, at 2:21 PM, Zachary Turner wrote:
> >
> > Yes I was doing it from inside the IDE though. I selected l
Is it one time until I reboot, or until the end of the test suite?
On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata wrote:
> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> It's updated now. I'm still getting
zturner added a comment.
if (!StreamIsValid())
{
if (DescriptorIsValid())
{
const char *mode = GetStreamOpenModeFromOptions (m_options);
if (mode)
{
if (!m_should_close_fd)
{
// We must duplicate the file d
e:
> On Mar 24, 2016, at 2:53 PM, Zachary Turner wrote:
>
> Is it one time until I reboot, or until the end of the test suite?
>
>
> The former.
>
> On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata wrote:
>
>> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb
zturner added inline comments.
Comment at: scripts/Python/python-typemaps.swig:532
@@ -531,3 +524,1 @@
- file.Clear();
-}
}
fjricci wrote:
> The problem is that here, we save the `FILE*` (`$1`) and let the `File`
> (`file`) go out of scope. So the `F
zturner added inline comments.
Comment at: scripts/Python/python-typemaps.swig:532
@@ -531,3 +524,1 @@
- file.Clear();
-}
}
zturner wrote:
> fjricci wrote:
> > The problem is that here, we save the `FILE*` (`$1`) and let the `File`
> > (`file`) go ou
$(lldb)/build/Debug/lldb
> $(lldb)/build/Debug/LLDB.framework
>
> where $(lldb) is your LLDB root folder...
>
>
>
>
>
> > On Mar 24, 2016, at 3:19 PM, Zachary Turner wrote:
> >
> > Figured as much. Thanks for the tip.
> >
> > Back to the issue of the test su
Could there be an overload of SBCommandReturnObject constructor that takes
an fd instead of a FILE*, and pass through to the private method which does
its own duping? Then this typemap could be changed to convert to int
instead of to FILE*
Also I'm OOO until tomorrow now, so I can't look at the co
This seems like an odd thing to do by default. Is there going to be a
setting to turn this off? Seems to me like off should be default
An enumerated setting would be even nicer, where one option is "report"
that just doesn't apply any FixIts, but prints a message saying "did you
mean Foo->bar()?"
are
> dereferencing down a few levels (e.g. "p
> myvar->subelem.valcontainer->value").
>
> Because lldb uses clang, we have to follow the rules of the language (for
> the most part) - this is likely the only way we could accomplish something
> similar in lldb.
>
As long as it only changes the private API and not the public it's probably
fine, if you think that will work feel free to give it a try and upload a
new patch
On Fri, Mar 25, 2016 at 9:12 AM Francis Ricci wrote:
> fjricci added a comment.
>
> Would we want this overloaded method taking an int (f
zturner added reviewers: labath, tberghammer.
zturner added a comment.
This seems very strange to me. What if someone specifies those flags on the
command line in the makefile instead of via some environment variables?
It also seems like a very specialized argument that we might use once or twi
zturner added a comment.
Couldn't we have a way to say in the Makefile "never use these flags", then the
test suite could check the environment and remove them if they are present.
This woudl allow the test to run.
architecture, compiler, etc are things we don't really have control over. If a
zturner added a comment.
I'll still wait and see what Pavel and/or Tamas say, but if we are going to go
this route, I would rather the argument be called `cflags` and now `env_flags`.
Xfailing a test based on an arbitrary environment variable just seems like
something we shouldn't be doing. I
Any particular reason this has the word Itanium baked into the name of the
class and description? MSVC doesn't use the Itanium ABI, but but AFAICT
from looking at this code, it should work for MSVC's abi as well.
Sicne this command isn't actually Itanium ABI specific, I don't think it
should make
like 1 per module.
On Fri, Mar 25, 2016 at 4:49 PM Enrico Granata wrote:
> On Mar 25, 2016, at 4:39 PM, Zachary Turner wrote:
>
> Any particular reason this has the word Itanium baked into the name of the
> class
>
>
> The name of the C++ language runtime is ItaniumABI
>
Did you get a chance to test this today?
On Fri, Mar 25, 2016 at 9:32 AM Greg Clayton wrote:
> Will do.
> > On Mar 24, 2016, at 3:30 PM, Zachary Turner wrote:
> >
> > Is there any way you could try it out for me? It still doesn't build
> successfully from the IDE
zturner updated this revision to Diff 51705.
zturner added a comment.
Rebased against ToT
http://reviews.llvm.org/D18381
Files:
include/lldb/Symbol/ClangASTContext.h
include/lldb/Symbol/ClangASTImporter.h
include/lldb/Symbol/ClangUtil.h
include/lldb/Symbol/TypeSystem.h
source/Plugins/
zturner added a comment.
Hi Greg, are you going to have a chance to try this out today?
http://reviews.llvm.org/D18381
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner requested changes to this revision.
zturner added a comment.
This revision now requires changes to proceed.
Mostly small comments, but a lot of them. Mostly around style issues such as
indentation, putting platform specific `#defines` in the right header file, and
some nuances around `_
zturner added inline comments.
Comment at: source/API/SystemInitializerFull.cpp:90
@@ -89,3 +89,3 @@
-#if defined(_MSC_VER)
+#if defined(_MSC_VER) || defined(__MINGW32__)
#include "lldb/Host/windows/windows.h"
Just use `LLVM_ON_WIN32` for both of these places,
zturner added a comment.
Everywhere I said `LLVM_ON_WINDOWS` earlier, it's actually called
`LLVM_ON_WIN32`.
http://reviews.llvm.org/D18519
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb
zturner added inline comments.
Comment at: source/API/SystemInitializerFull.cpp:90
@@ -89,3 +89,3 @@
-#if defined(_MSC_VER)
+#if defined(_MSC_VER) || defined(__MINGW32__)
#include "lldb/Host/windows/windows.h"
eran.ifrah wrote:
> zturner wrote:
> > Just use `LL
Author: zturner
Date: Mon Mar 28 17:53:41 2016
New Revision: 264685
URL: http://llvm.org/viewvc/llvm-project?rev=264685&view=rev
Log:
Move some functions from DWARFASTParserClang to ClangASTImporter.
This allows these functions to be re-used by a forthcoming
PDBASTParser. The functions in questi
This revision was automatically updated to reflect the committed changes.
Closed by commit rL264685: Move some functions from DWARFASTParserClang to
ClangASTImporter. (authored by zturner).
Changed prior to commit:
http://reviews.llvm.org/D18381?vs=51705&id=51848#toc
Repository:
rL LLVM
htt
zturner created this revision.
zturner added reviewers: spyffe, clayborg.
zturner added a subscriber: lldb-commits.
This is pretty mechanical, so you don't really have to look at this in too much
detail. I'm mostly posting it here to make sure people are ok with the high
level idea. Basically
It's night here, so I will have a detailed look tomorrow. But in the
meantime, some of the issues don't appear to be addressed. For example the
issue about why logging is disabled, the disabled code in
ProcessWinMiniDump.cpp, and a few other things. If you view the diff in
Phabricator, you can r
zturner added a subscriber: zturner.
zturner added a comment.
It's night here, so I will have a detailed look tomorrow. But in the
meantime, some of the issues don't appear to be addressed. For example the
issue about why logging is disabled, the disabled code in
ProcessWinMiniDump.cpp, and a fe
know if I can continue this effort without review, it would save all
of us some time and obviously I can use my judgement if I think the change
is non-trivial.
On Mon, Mar 28, 2016 at 4:32 PM Zachary Turner wrote:
> zturner created this revision.
> zturner added reviewers: spyffe, clayborg.
zturner added a comment.
One or two of the functions, you are right. They do `clang::ASTContext`
related things. That was actually an oversight on my part. I meant to move
only functions that specifically did NOT do `clang::ASTContext` things. Like
`RemoveFastQualifiers`, or converting enum
zturner added a reviewer: rsmith.
zturner added a comment.
But wouldn't doing that manual merge once then make things easier for the
future? For example, if you merge back to a branch that doesn't have
`ClangUtil.cpp`, and then you just add `ClangUtil.cpp` to that branch, the
problem is solved
zturner added a comment.
In http://reviews.llvm.org/D18530#387328, @tberghammer wrote:
> I don't maintain any downstream branch to worry about merges but my personal
> opinion is moving large amount of code around can cause some issue in the
> future even for upstream. The 2 main issue I can th
zturner added a comment.
So, in thinking about this some more, my end goal does not necessarily involve
the creation of a new file. The primary goal is group related functions
together into a more bite-sized interface in order to make it easier to
understand the code.
How about keeping everyt
zturner added a comment.
In http://reviews.llvm.org/D18530#387382, @clayborg wrote:
> In http://reviews.llvm.org/D18530#387377, @zturner wrote:
>
> > So, in thinking about this some more, my end goal does not necessarily
> > involve the creation of a new file. The primary goal is group related
zturner added a comment.
The last time we talked about this, you said something along the lines of
"Changes to LLVM and LLDB at the same time are a problem, but any refactor that
happens entirely within LLDB is fine"
http://reviews.llvm.org/D18530
___
zturner added a comment.
I will move most of this back to `ClangASTContext`, but I want to state again
that I would like to reach a point where downstream merge issues are not even a
topic that comes up in code reviews. I see many huge refactors coming through
from people that do not go up for
I think it depends on how bad the thing that happens is. If you are out of
memory, sure you can assert. If a syscall fails that is supposed to never
fail, you can assert. But if one piece of debug info appears corrupt, I
don't think it's worth bringing down the whole process, which could be an
e
nd if you absolutely can't recover, it's
>> worth the time to think about whether you could recover if you architected
>> the code a little differently.
>>
>> But in the case of debug information, you should always be able to fall
>> back to "no debug in
What if you are simultaneously debugging 2 processes with the same pid?
Does this fail?
On Fri, Apr 1, 2016 at 9:06 AM Pavel Labath wrote:
> labath created this revision.
> labath added reviewers: clayborg, zturner.
> labath added a subscriber: lldb-commits.
>
> There was a bug in linux core file
zturner added a subscriber: zturner.
zturner added a comment.
FWIW I believe we do actually want many of the PE headers, although I have to
say I don't like the format of the output.It seems like we could break this
up into smaller chunks like section headers, pe headers, binary headers, deb
zturner added a comment.
Ugh. The only better way I can think of to do this would be to go into LLVM
and rip out all the preprocessor defines, and compile `_windows` and `_posix`
versions of every function unconditionally, and then only use the preprocessor
defines to do something like:
#if
zturner added a comment.
A few minor points left. Most are just CMake indentation issues, so should be
easy to fix. A few code changes though.
Comment at: CMakeLists.txt:3-5
@@ -2,1 +2,5 @@
+if(MINGW_DEBUG)
+# force debugging info into lldb sources
+message("-- Buil
Author: zturner
Date: Fri Apr 1 18:20:35 2016
New Revision: 265200
URL: http://llvm.org/viewvc/llvm-project?rev=265200&view=rev
Log:
Add some unit tests for ClangASTContext.
In doing so, two bugs were uncovered (and fixed). The first bug
is that ClangASTContext::RemoveFastQualifiers() was broke
I think we need some more information before we xfail this. It would help
to drill down to either the python import statement or the
PyImport_ImportModule C api call that actually does the import.
If you can get that, i can help come up with a fix. Just need to step
through the execution of the co
h relative and
> absolute module paths changed from Python 2 to 3.
>
> I'll revert the xfail if you want. But this has been broken for quite a
> while (as has another test, which I'm looking into now).
>
> On Tue, Apr 5, 2016 at 2:29 PM, Zachary Turner wrote:
>
>&g
Without the modification to sys.path
On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner wrote:
> Can you try to change "import foo2" to "from .foo import foo2"
> On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy
> wrote:
>
>> I've drilled down in
t does the right thing. I'll keep investigating.
>
> On Tue, Apr 5, 2016 at 3:40 PM, Zachary Turner wrote:
>
>> Without the modification to sys.path
>>
>> On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner wrote:
>>
>>> Can you try to change "impo
e. Otherwise everybody will have to put this goo
> at the top of every .py file they write for formatters & breakpoint
> commands and the like.
>
> Jim
>
>
> > On Apr 5, 2016, at 5:30 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrot
file path.
>
> And does the `from __future__ import absolute_import` really belong in the
> script your importing? Or does it belong in the temp script that's written
> to do the import? I would have thought the latter from everything I read
> yesterday.
>
> On Tue, Apr 5
/test/use_lldb_suite.py
On Wed, Apr 6, 2016 at 8:19 AM Zachary Turner wrote:
> Well, it would belong anywhere that does an import, so in theory it
> belongs in every script. In the general case, for example if you are like
> this:
>
> foo
> |-- bar
> | baz
> |-- b
zturner created this revision.
zturner added a reviewer: clayborg.
zturner added a subscriber: lldb-commits.
This code is still untested aside from that it compiles. I mostly want to put
an early work-in-progress up here to make sure I'm on the right path and am not
doing anything fundamentally
zturner added inline comments.
Comment at: source/Plugins/SymbolFile/PDB/PDBASTParser.cpp:154-156
@@ +153,5 @@
+
+CompilerType clang_type =
+m_ast.CreateRecordType(tu_decl_ctx, access,
udt->getName().c_str(), TranslateUdtKind(udt_kind),
+
zturner added a comment.
In http://reviews.llvm.org/D18848#394756, @clayborg wrote:
> > One oddity of PDB is that the debug info does not maintain enough
> > information to accurately reconstruct the DeclContext hierarchy. If you
> > have this:
>
> >
>
> > namespace Foo
>
> > {
>
> >
zturner added a subscriber: zturner.
zturner added a comment.
Hi Jackson,
Two suggestions:
1. Please clang-format the patch. Let me know if you need help getting this
working.
2. use C++11 threads instead of pthreads. This makes the tests portable to
Windows. Even if the test still fails on
zturner added a comment.
We have an lldb style file in llvm/tools/lldb, it should be picked up
automatically if you run it from the lldb directory. I'm not sure though if
it's based on the folder you're in when you run clang-format or by
searching up the tree from the target file until it finds a
We have an lldb style file in llvm/tools/lldb, it should be picked up
automatically if you run it from the lldb directory. I'm not sure though if
it's based on the folder you're in when you run clang-format or by
searching up the tree from the target file until it finds a rule file
On Thu, Apr 7, 2
zturner accepted this revision.
zturner added a reviewer: zturner.
zturner added a comment.
This revision is now accepted and ready to land.
Looks fine to me. TBH I haven't seen any of the lldb-mi owners around in
months, so I'm not sure if they're still active
http://reviews.llvm.org/D18880
zturner added a comment.
Greg, what should happen when you look up a builtin type like "char" or
"float"? Is there supposed to be a unique `TypeSP` for this somewhere, with a
unique uid?
http://reviews.llvm.org/D18848
___
lldb-commits mailing lis
zturner added a comment.
I mean for example if someone calls `FindTypes(..., "char", ...);
Should a `TypeSP` go into the map?
http://reviews.llvm.org/D18848
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mai
zturner added a comment.
How about add a function to `lldbsuite\support\fs.py`?
def remove_file(file, num_retries, sleep_duration):
Then just call this everywhere you need to. Could even nuke this whole
`RemoveTempFile` method.
http://reviews.llvm.org/D18912
zturner added inline comments.
Comment at: packages/Python/lldbsuite/test/lldbtest.py:1994
@@ +1993,3 @@
+# failure and retry.
+def remove_file(file, num_retries = 1, sleep_duration = 0.5):
+while True:
I think the default for `num_retries` should be 0. Usual
1901 - 2000 of 3010 matches
Mail list logo
