Author: zturner
Date: Tue Apr 2 12:39:45 2019
New Revision: 357513
URL: http://llvm.org/viewvc/llvm-project?rev=357513&view=rev
Log:
[NativePDB] Don't fail on import modules.
A recent patch to LLD started emitting information about import modules.
These are represented as compile units in the PD
Author: zturner
Date: Thu Mar 21 09:34:58 2019
New Revision: 356682
URL: http://llvm.org/viewvc/llvm-project?rev=356682&view=rev
Log:
Move the rest of the sections over to DWARFContext.
This is mostly mechanical, and just moves the remaining non-DWO
related sections over to DWARFContext.
Differe
Author: zturner
Date: Wed Mar 20 13:49:25 2019
New Revision: 356612
URL: http://llvm.org/viewvc/llvm-project?rev=356612&view=rev
Log:
Introduce DWARFContext.
LLVM's DWARF parsing library has a class called DWARFContext which holds
all of the various DWARF data sections and lots of other informati
Author: zturner
Date: Tue Mar 19 13:08:56 2019
New Revision: 356509
URL: http://llvm.org/viewvc/llvm-project?rev=356509&view=rev
Log:
Delete more dead code.
All of this is code that is unreferenced. Removing as much of
this as possible makes it more easy to determine what functionality
is missin
Author: zturner
Date: Tue Mar 19 11:32:43 2019
New Revision: 356495
URL: http://llvm.org/viewvc/llvm-project?rev=356495&view=rev
Log:
Remove some dead DWARF enum -> string conversion functions.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp
lldb/trunk/source/Plugins
Author: zturner
Date: Tue Mar 19 11:06:32 2019
New Revision: 356490
URL: http://llvm.org/viewvc/llvm-project?rev=356490&view=rev
Log:
Delete dead code.
Most of these are Dump functions that are never called, but there
is one instance of entire unused classes (DWARFDebugMacinfo and
DWARFDebugMacin
Author: zturner
Date: Tue Mar 19 09:26:08 2019
New Revision: 356469
URL: http://llvm.org/viewvc/llvm-project?rev=356469&view=rev
Log:
Remove a couple of log statements.
These log statements have questionable value, and hinder the effort
of separating the high and low level DWARF parsing interface
Author: zturner
Date: Fri Mar 15 11:00:43 2019
New Revision: 356284
URL: http://llvm.org/viewvc/llvm-project?rev=356284&view=rev
Log:
Abbreviation declarations are required to have non-null tags.
Treat a null tag as an error.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFAbbrevia
Author: zturner
Date: Fri Mar 15 10:32:05 2019
New Revision: 356278
URL: http://llvm.org/viewvc/llvm-project?rev=356278&view=rev
Log:
Return Error and Expected from more DWARF interfaces.
This continues the work of introducing Error and Expected into
the DWARF parsing interfaces, this time for th
On Thu, Mar 14, 2019 at 11:48 AM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg accepted this revision.
> clayborg added a comment.
> This revision is now accepted and ready to land.
>
> As long as there is not a large performance regress when parsing large
> DWARF file
Author: zturner
Date: Thu Mar 14 12:05:55 2019
New Revision: 356190
URL: http://llvm.org/viewvc/llvm-project?rev=356190&view=rev
Log:
Return llvm::Error and llvm::Expected from DWARF parsing code.
The goal here is to improve our error handling and error recovery while
parsing DWARF, while at the
Make sure to run the test suite after these kinds of changes. You might be
surprised.
On Thu, Mar 14, 2019 at 10:21 AM Davide Italiano via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: davide
> Date: Thu Mar 14 10:23:08 2019
> New Revision: 356171
>
> URL: http://llvm.org/viewvc/l
Author: zturner
Date: Tue Mar 12 13:51:05 2019
New Revision: 355975
URL: http://llvm.org/viewvc/llvm-project?rev=355975&view=rev
Log:
Remove support for DWARF64.
LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support
for DWARF64 is only partial, and if enabled appears to also not wor
Author: zturner
Date: Tue Mar 12 13:50:29 2019
New Revision: 355973
URL: http://llvm.org/viewvc/llvm-project?rev=355973&view=rev
Log:
Move ElaboratingDIEIterator into implementation file.
This is not used outside of the private implementation of the class,
so hiding in the implementation file is
Author: zturner
Date: Tue Mar 12 13:50:46 2019
New Revision: 355974
URL: http://llvm.org/viewvc/llvm-project?rev=355974&view=rev
Log:
Remove DWARFDIECollection.
This is a very thin wrapper over a std::vector and does
not seem to provide any real value over just using a container
directly.
Differ
+1. I’ve seen some of the changes in llvm that have changed asserts to
return a default value. IMHO these should be changed to return Expected
instead
On Tue, Mar 12, 2019 at 1:16 PM Jonas Devlieghere via Phabricator <
revi...@reviews.llvm.org> wrote:
> JDevlieghere added a comment.
>
> In D59235#
Fair enough, a FIXME sounds reasonable.
On Tue, Mar 12, 2019 at 10:33 AM Jan Kratochvil via Phabricator <
revi...@reviews.llvm.org> wrote:
> jankratochvil added inline comments.
>
>
>
> Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp:263
>uint64_t length
On Mon, Mar 11, 2019 at 4:15 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Just to be precise: TypeImpl stores a TypePair for the static type and a
> CompilerType for the dynamic type. These two have different meanings.
> There's no assumption about the relationship betwe
Yes, it’s not the case here but even it were, just because the Python
interface exposes this api doesn’t mean we have to use it internally.
Regardless, this particular class is completely private and has no analogue
in the SB API
On Fri, Mar 8, 2019 at 4:53 PM Adrian Prantl via Phabricator <
revi.
Author: zturner
Date: Fri Mar 8 12:56:10 2019
New Revision: 355730
URL: http://llvm.org/viewvc/llvm-project?rev=355730&view=rev
Log:
Remove dependency edges from Host to Target/Core.
After recent changes, Host is now dependency-free.
Modified:
lldb/trunk/source/Host/CMakeLists.txt
lldb/
Author: zturner
Date: Thu Mar 7 16:11:27 2019
New Revision: 355656
URL: http://llvm.org/viewvc/llvm-project?rev=355656&view=rev
Log:
[lldb-vscode] Report an error if an invalid program is specified.
Previously if an invalid program was specified, there was a bug
which, when we attempted to launc
Author: zturner
Date: Thu Mar 7 13:23:21 2019
New Revision: 355637
URL: http://llvm.org/viewvc/llvm-project?rev=355637&view=rev
Log:
[lldb-vscode] Support running in server mode on Windows.
Windows can't use standard i/o system calls such as read and write
to work with sockets, it instead needs
Author: zturner
Date: Wed Mar 6 14:42:34 2019
New Revision: 39
URL: http://llvm.org/viewvc/llvm-project?rev=39&view=rev
Log:
Pass /bigobj for SBReproducer.cpp with MSVC
/BIGOBJ is used to bypass certain COFF file format
limitations and is used with, unsurprisingly, very big
object files.
Author: zturner
Date: Wed Mar 6 14:30:06 2019
New Revision: 37
URL: http://llvm.org/viewvc/llvm-project?rev=37&view=rev
Log:
[lldb-vscode] Correctly propagate errors back to VS Code.
Modified:
lldb/trunk/tools/lldb-vscode/lldb-vscode.cpp
Modified: lldb/trunk/tools/lldb-vscode/lldb-v
Author: zturner
Date: Wed Mar 6 11:14:41 2019
New Revision: 355536
URL: http://llvm.org/viewvc/llvm-project?rev=355536&view=rev
Log:
Try again to fix OSX compilation failure.
Modified:
lldb/trunk/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.cpp
Modified: lldb/trunk/source/Plugins/S
Author: zturner
Date: Wed Mar 6 10:44:27 2019
New Revision: 355531
URL: http://llvm.org/viewvc/llvm-project?rev=355531&view=rev
Log:
Try to fix OSX compilation failure.
Modified:
lldb/trunk/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
Modified: lldb/trunk/source/Plugins/Process/MacOS
Author: zturner
Date: Wed Mar 6 10:20:23 2019
New Revision: 355528
URL: http://llvm.org/viewvc/llvm-project?rev=355528&view=rev
Log:
Resubmit "Don't include UnixSignals.h from Host."
This was reverted because it breaks the GreenDragon bot, but
the reason for the breakage is lost, so I'm resubmit
How about SerializationFormats?
On Tue, Mar 5, 2019 at 12:22 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> FileFormats wouldn't be generic enough to capture the gdb-remote or
> debug-info-server protocol code. However, even calling gdb-remote prot
Author: zturner
Date: Mon Mar 4 13:51:03 2019
New Revision: 355342
URL: http://llvm.org/viewvc/llvm-project?rev=355342&view=rev
Log:
Move ProcessInfo from Host to Utility.
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. Ho
Author: zturner
Date: Mon Mar 4 11:57:04 2019
New Revision: 355329
URL: http://llvm.org/viewvc/llvm-project?rev=355329&view=rev
Log:
Fix Windows build after UserIDResolver patch.
That patch added a function to HostInfo that returns an instance
of UserIDResolver, but this function was unimplement
Author: zturner
Date: Wed Feb 27 13:53:08 2019
New Revision: 355037
URL: http://llvm.org/viewvc/llvm-project?rev=355037&view=rev
Log:
Remove dependency from Host -> Core.
I wasn't actually trying to eliminate this one, but looks like
it happened as a side effect of moving Symbols out of Host.
Mo
While it’s a good chuckle, can you elaborate on what exactly the commit
message means?
On Fri, Feb 22, 2019 at 5:07 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: jingham
> Date: Fri Feb 22 17:08:17 2019
> New Revision: 354711
>
> URL: http://llvm.org/viewvc/llvm-pr
Author: zturner
Date: Fri Feb 15 12:43:56 2019
New Revision: 354168
URL: http://llvm.org/viewvc/llvm-project?rev=354168&view=rev
Log:
Don't include UnixSignals.h from Host.
Host had a function to get the UnixSignals instance corresponding
to the current host architecture. This means that Host ha
Try `import distutils.LooseVersion` and use that to do the comparison.
On Wed, Feb 13, 2019 at 4:49 PM Frederic Riss via Phabricator <
revi...@reviews.llvm.org> wrote:
> friss created this revision.
> friss added reviewers: zturner, labath.
> Herald added a reviewer: serge-sans-paille.
> Herald ad
lgtm!
On Mon, Feb 11, 2019 at 7:19 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov added a comment.
>
> Thanks for the help with the tests, it looks like they are ok now! So can
> we proceed with this patch?
>
>
> Repository:
> rLLDB LLDB
>
> CHANGES SI
Lgtm!
On Mon, Feb 11, 2019 at 12:11 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov added a comment.
>
> Zachary, can you take a look? please?
>
>
> Repository:
> rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
> https://reviews.llvm.org/D57809/new/
>
> https
Yes, clang tries to find the visual studio installation, because that is
how it can find headers and libs. Can you make a separate patch with the
changes to build.py and upload that?
On Tue, Feb 5, 2019 at 2:34 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.ur
Oh I guess because one of them has const values? Oh well, ignore my
suggestion then :)
On Wed, Jan 30, 2019 at 10:50 AM Davide Italiano via Phabricator <
revi...@reviews.llvm.org> wrote:
> davide marked an inline comment as done.
> davide added inline comments.
>
>
>
> Comment a
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
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.
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
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
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
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: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: 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: 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: 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: 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: 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: 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
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
The same plugin is being used in both cases, the patch only touches the
nonnative PDB reader. The followup changes to the plugin itself are
necessary because the results were not identical (another reason i want to
de-support ParseDeclsForContext at global acope - having 2 implementations
of the sa
Waiiit a second. Why don't we just teach obj2yaml and yaml2obj to
round-trip minidumps? This way you could run it on a minidump, then
hand-edit it to customize some bits you want to change, then check in the
yaml.
On Fri, Jan 4, 2019 at 10:56 AM Greg Clayton wrote:
>
> On Jan 4, 2019, at 9
You're right, it wouldn't. I didn't think of that. I guess the obj ->
yaml round-tripping would be the only way in that case, and the tool would
need to be fixed first so that it can round trip executable object files.
On Fri, Jan 4, 2019 at 9:46 AM Leonard Mosescu wrote:
> ouldn’t we have lld
It seems like this test could be made to work with non dwarf debug info by
compiling a real source file. WDYT?
On Fri, Jan 4, 2019 at 5:31 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
> labath added reviewers: clayborg, zturner.
> Herald added
For those kinds of cases, we could use obj2yaml and check in yaml right?
Fwiw I tried to round-trip an exe through obj->yaml->obj recently and the
resulting exe was incorrect but it was close, so I think there’s only some
small fixes needed.
In regards to your previous response, couldn’t we have l
Ok, lgtm then
On Wed, Jan 2, 2019 at 11:53 PM Pavel Labath wrote:
> On 02/01/2019 18:32, Zachary Turner wrote:
> > Just to be sure, this new test will fail without your Symtab changes
> > right? I'm not in a state where I can look at code right now, and you
> > say anything that symbolicates an
Very excited to see this. I'm technically on vacation so I might not be
able to review it immediately, but I'm looking forward to getting to it
soon.
On Wed, Jan 2, 2019 at 4:36 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith created this revision.
> asmith added revie
Author: zturner
Date: Wed Jan 2 13:04:22 2019
New Revision: 350262
URL: http://llvm.org/viewvc/llvm-project?rev=350262&view=rev
Log:
Try to fix Green Dragon bot.
It doesn't like this std::tie() for some reason, hopefuly this
fixes it.
Modified:
lldb/trunk/source/Plugins/SymbolFile/NativePDB
Author: zturner
Date: Wed Jan 2 10:53:11 2019
New Revision: 350244
URL: http://llvm.org/viewvc/llvm-project?rev=350244&view=rev
Log:
Use map::insert instead of try_emplace.
try_emplace is C++17.
Modified:
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp
Modified: lldb/trunk/sour
Author: zturner
Date: Wed Jan 2 10:33:54 2019
New Revision: 350243
URL: http://llvm.org/viewvc/llvm-project?rev=350243&view=rev
Log:
[NativePDB] Implement ParseDeclsForContext.
This is a first step towards getting lldb-test symbols working
with the native plugin. There is a remaining issue, whi
Author: zturner
Date: Wed Jan 2 10:33:32 2019
New Revision: 350242
URL: http://llvm.org/viewvc/llvm-project?rev=350242&view=rev
Log:
[NativePDB] Update function-types-classes test to check VarDecls.
A Previous patch added support for creating VarDecls for global
variables. This patch updates th
Author: zturner
Date: Wed Jan 2 10:32:50 2019
New Revision: 350240
URL: http://llvm.org/viewvc/llvm-project?rev=350240&view=rev
Log:
[NativePDB] Fix setting breakpoint by file and line.
There were several problems preventing this from working. The
first is that when the PDB had an absolute path
Just to be sure, this new test will fail without your Symtab changes
right? I'm not in a state where I can look at code right now, and you say
anything that symbolicates an address *can* use the symtab, but I don't
know if you really meant *must* use the symtab.
On Wed, Jan 2, 2019 at 12:19 AM Pa
Sorry, this comment was supposed to be deleted after I realized i was wrong.
On Sat, Dec 29, 2018 at 9:12 PM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov marked an inline comment as done.
> aleksandr.urakov added inline comments.
>
>
>
>
Author: zturner
Date: Thu Dec 20 15:32:37 2018
New Revision: 349854
URL: http://llvm.org/viewvc/llvm-project?rev=349854&view=rev
Log:
[NativePDB] Create VarDecls for global variables.
Previously we would create these for local variables but not for
global variables.
Also updated existing tests w
Author: zturner
Date: Wed Dec 19 14:50:22 2018
New Revision: 349692
URL: http://llvm.org/viewvc/llvm-project?rev=349692&view=rev
Log:
Fix line endings.
Modified:
lldb/trunk/lit/SymbolFile/NativePDB/nested-types.cpp
Modified: lldb/trunk/lit/SymbolFile/NativePDB/nested-types.cpp
URL:
http://l
Author: zturner
Date: Wed Dec 19 12:00:25 2018
New Revision: 349675
URL: http://llvm.org/viewvc/llvm-project?rev=349675&view=rev
Log:
[NativePDB] Enable function-level-linking.test in native mode.
This test passes with the native reader, so run it in both modes.
Modified:
lldb/trunk/lit/Symb
Author: zturner
Date: Wed Dec 19 11:45:30 2018
New Revision: 349673
URL: http://llvm.org/viewvc/llvm-project?rev=349673&view=rev
Log:
[NativePDB] Fix a use after free and enable corresponding native test.
We had a use after free where we were assigning the result of a function
that returned a str
Author: zturner
Date: Tue Dec 18 15:12:08 2018
New Revision: 349565
URL: http://llvm.org/viewvc/llvm-project?rev=349565&view=rev
Log:
[NativePDB] Correctly reconstruct DeclContext for nested enums.
We reconstruct the AST hierarchy by trying to hack up a mangled
name for the parent type using the
Author: zturner
Date: Mon Dec 17 13:33:08 2018
New Revision: 349399
URL: http://llvm.org/viewvc/llvm-project?rev=349399&view=rev
Log:
Fix case of source file in CMakeLists.txt
Modified:
lldb/trunk/source/Plugins/SymbolFile/NativePDB/CMakeLists.txt
Modified: lldb/trunk/source/Plugins/SymbolFi
Author: zturner
Date: Mon Dec 17 11:43:33 2018
New Revision: 349383
URL: http://llvm.org/viewvc/llvm-project?rev=349383&view=rev
Log:
[NativePDB] Decouple AST reconstruction from lldb Symbol creation.
Previously the code that parsed debug info to create lldb's Symbol
objects such as Variable, Typ
Author: zturner
Date: Mon Dec 17 08:15:13 2018
New Revision: 349360
URL: http://llvm.org/viewvc/llvm-project?rev=349360&view=rev
Log:
[Clang AST Context] Add a few helper functions.
The first one allows us to add an enumerator to an enum if we
already have an APSInt, since ultimately the implemen
Don't we print the environment in verbose mode? Can we see that output as
well?
On Fri, Dec 14, 2018 at 11:53 AM Stella Stamenova
wrote:
> The verbose output is below. If I run the two commands on the command
> line, they both succeed, but when I run them through build.py, the link
> command is
Ahh, so I misinterpreted what you originally said. There is one Clang AST *per
SymboFile*. In PDB land, compile units are often called "modules" so it's
easy to get confused. So in my original response, what I actually meant
was that there's no notion of a per compile-unit AST. But that also ha
If you do decide to unsilence it, then just mark those skip and file bugs
for them being flaky.
On Fri, Dec 14, 2018 at 11:11 AM Stella Stamenova
wrote:
> An unexpected pass makes the bot red. I might un-silence it despite the
> couple of issues left anyway, but it’s something to be aware of.
>
An unexpected pass won't make the bot red will it? If so, one option is to
mark them skip, just to make sure we can get the bot turned on as quickly
as possible.
On Fri, Dec 14, 2018 at 10:56 AM Stella Stamenova
wrote:
> It’s actually not green – the unexpected passes are counted as a failure.
I've fixed it. It looks like the bot should be green again once this test
starts passing. Can you make it noisy and starting to send emails now?
On Fri, Dec 14, 2018 at 10:42 AM Zachary Turner wrote:
> Ahh, that seems easy enough to fix. Just need to change the 7 to a
> {{.*}}. Since we're a
be
hard to make this work.
On Fri, Dec 14, 2018 at 10:51 AM Pavel Labath wrote:
> On 14/12/2018 19:43, Zachary Turner via lldb-commits wrote:
> > Author: zturner
> > Date: Fri Dec 14 10:43:42 2018
> > New Revision: 349175
> >
> > URL: http://llvm.org/view
Author: zturner
Date: Fri Dec 14 10:43:42 2018
New Revision: 349175
URL: http://llvm.org/viewvc/llvm-project?rev=349175&view=rev
Log:
[NativePDB] Fix local-variables.cpp test.
Since we're actually running an executable on the host now, different
versions of Windows could load different system lib
Ahh, that seems easy enough to fix. Just need to change the 7 to a
{{.*}}. Since we're actually compiling and running a process on the
buildbot, different versions of Windows will affect this.
On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
>
I can't access the buildbot right now, it's just timing out and never
loading the webpage. If you have it open and can paste the output here I
can try to figure out what's wrong, otherwise I'll have to wait for it to
become available again.
On Fri, Dec 14, 2018 at 10:31 AM Stella Stamenova via Ph
That said, as you mentioned this enables other developers to start working
on things, and if that means we can get the SymbolVendor in more quickly,
then we can get rid of this more quickly. I just really want to converge
towards the permanent solution, rather than away from it, so if committing
t
The permanent solution would be figuring out what to do about the
ObjectFile situation (e.g. do we want to make an ObjectFilePDB or do we
want to live in a world where SymbolFiles need not be backed by
ObjectFiles?), and then regardless of what we decide there, implementing
the SymbolVendor that ca
At this point it seems like perpetuating the hack, or at least even if
that's the direction we decide to go longterm, not implementing that
solution fully and missing some of the corner cases.
So I think I'd rather just go with the original hack of checking the
current directory at this point. St
The problems I have with current directory lookup are:
* It makes the behavior dependent on the environment, much like using an
environment variable. This is a potential source of flakiness in tests, or
different behavior on different peoples' machines.
* It doesn't match WinDbg or MSVC
* It's te
I think we can fix that by changing the line to:
```
if (!object_file || object_file->GetFileSpec() == symbol_fspec) {
}
```
On Thu, Dec 13, 2018 at 12:04 PM Pavel Labath wrote:
> On 13/12/2018 19:32, Leonard Mosescu wrote:
> > What's the consensus?
> >
> > Personally I think that, even conside
Well, Visual Studio also supports remote debugging, and searching next to
the .dmp is just one of several places it looks. And LLDB also supports
local debugging, and so looking next to the .dmp file, being consistent
with Visual Studio, will be the expected behavior for people using LLDB in
local
Author: zturner
Date: Thu Dec 13 10:17:51 2018
New Revision: 349067
URL: http://llvm.org/viewvc/llvm-project?rev=349067&view=rev
Log:
[NativePDB] Add support for local variables.
This patch adds support for parsing and evaluating local variables.
using the native pdb plugin.
Differential Revisio
On irc earlier i was talking about this with Greg and he said it should be
fine in his opinion. I’ll point him to this review in the morning so he can
comment
On Thu, Dec 13, 2018 at 3:30 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added inline comments.
>
>
> =
Author: zturner
Date: Wed Dec 12 09:17:53 2018
New Revision: 348941
URL: http://llvm.org/viewvc/llvm-project?rev=348941&view=rev
Log:
[ast] CreateParameterDeclaration should use an appropriate DeclContext.
Previously CreateParameterDeclaration was always using the translation
unit DeclContext. W
There is another option which I was just made aware of. LLDB already has a
setting called `target.debug-file-search-paths`. This is basically a
symbol path. If you call Symbols::LocateExecutableSymbolFile, it will
already add use this setting, and moreover it will implicitly add current
working
It's fine, I was mostly just curious.
On Wed, Dec 12, 2018 at 8:52 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath marked an inline comment as done.
> labath added inline comments.
>
>
>
> Comment at: lldb/trunk/lit/helper/build.py:630
> +a
On Tue, Dec 11, 2018 at 4:22 PM Leonard Mosescu wrote:
> I guess I don't see why we need a temporary solution at all. If we can
>> have logic that can be rolled into the SymbolVendor when we get it, and
>> makes sense there, and is also simple, why not go with it? Failing that,
>> doesn't the `
I guess I don't see why we need a temporary solution at all. If we can
have logic that can be rolled into the SymbolVendor when we get it, and
makes sense there, and is also simple, why not go with it? Failing that,
doesn't the `target symbols add` solution also work fine?
On Tue, Dec 11, 2018 a
Actually, Adrian just tested this on his machine and it did look in his
minidump folder. I don't know why we're seeing different behavior. Either
way, regardless of whether MSVC / WinDbg look in the minidump folder, I
still think it's a pretty intuitive location to add in the default search
path.
Only one way to know for sure, and that's to test it :) So I did.
Yes, it will search the directory of the EXE for the PDB. But here, we're
talking about a situation where there is no EXE, only a minidump. If there
is a minidump and no EXE then neither WinDbg nor VS will search the
minidump fol
On Tue, Dec 11, 2018 at 11:57 AM Pavel Labath wrote:
> The part I know nothing about is whether something similar could be done
> for PE/COFF files (and I'll need something like that there too). Adrian,
> Zachary, what is the relation ship between "image base" of an object
> file and its sections
I meant the location of the minidump. So if you have C:\A\B\C\foo.dmp
which is the dump file for bar.exe which crashed on another machine, then
it would look for C:\A\B\C\bar.pdb. That actually seems like fairly
intuitive behavior to me, but maybe I'm in the minority :)
We can see what Pavel, Ad
1 - 100 of 2276 matches
Mail list logo
