Author: zturner
Date: Mon Nov 19 08:47:06 2018
New Revision: 347224
URL: http://llvm.org/viewvc/llvm-project?rev=347224&view=rev
Log:
[lit] On Windows, don't error if MSVC is not in PATH.
We had some logic backwards, and as a result if MSVC was not found
in PATH we would throw a string concatenat
Lgtm
On Wed, Nov 21, 2018 at 12:10 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova created this revision.
> stella.stamenova added reviewers: labath, zturner, asmith.
> Herald added subscribers: lldb-commits, jfb.
>
> Right now only some platforms add pthr
There’s actually been a slow push away from cl::opt. It’s less flexible and
doesn’t support some things that the TableGen approach does. Recently
there’s been a few efforts to port existing tools onto TableGen options
from cl::opt.
I don’t think cl::opt is going away anytime soon so if it works I
One potentially nice way to test this would be to have all the -O, -o, -S,
-s, -Q, and -q just run "script print(N)" where N is some number that
changes at each line, then FileCheck the output
On Mon, Nov 26, 2018 at 6:38 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham
I can repro this, so I'll work on a fix.
On Wed, Nov 28, 2018 at 12:38 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added a comment.
>
> I ran the tests with this change and there are about a dozen new failures:
>
> 2018-11-28T20:25:29.2437909Z
Yea, I don't really want to fix it there though because the problem will
just happen again. I think it should be done inside of ToolSubst.
On Wed, Nov 28, 2018 at 12:59 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added a comment.
>
> It works for me
Objects have a symbol table, but a Module is just a loaded object file. And
a loaded object file can have multiple symbol tables (from the object file,
or symbol file, etc).
Would it make sense to have Module provide a GetSymtab method that can find
all appropriate Symtabs and present a unified vi
It would be great if future work could go towards the native pdb plugin. To
be honest, I’m trying very hard to get it to the point that the DIA plugin
can be deleted, so large pieces of new functionality that only go to the
DIA plugin are, in a way, wasted effort. I’m currently working on getting
a
Author: zturner
Date: Fri Nov 30 16:22:21 2018
New Revision: 348058
URL: http://llvm.org/viewvc/llvm-project?rev=348058&view=rev
Log:
[lit] Add a generic build script with a lit substitution.
This adds a script called build.py as well as a lit substitution
called %build that we can use to invoke
In that case, can we implement that method first? I was planning to do it
this week, but if someone else wants to do it immediately that’s fine too
On Mon, Dec 3, 2018 at 8:11 AM Leonid Mashinskiy via Phabricator <
revi...@reviews.llvm.org> wrote:
> leonid.mashinskiy added a comment.
>
> Seems lik
Is the only reason we need these methods so that we can use lldb-test? If
so, perhaps the tests can be written in terms of lldb itself, similar to
the existing NativePDB tests
On Mon, Dec 3, 2018 at 8:39 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov adde
Ok that makes sense. I’ll work on this soon, I’m trying to get all existing
dia PDB tests passing with the native plugin so i can delete old plugin, so
I’ll keep this in mind and probably do this next.
I’m trying to fix some bugs in clang so that we emit compatible debug info
to msvc, which curren
Perhaps use %t.bogus? instead of /bogus?
On Mon, Dec 3, 2018 at 12:39 PM Jonas Devlieghere via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: jdevlieghere
> Date: Mon Dec 3 12:36:21 2018
> New Revision: 348186
>
> URL: http://llvm.org/viewvc/llvm-project?rev=348186&view=rev
> Log:
I will just add that once upon a time, there was a test in LLVM that worked
similar to this, and so it would try to open a file like /foo/foo.txt, and
expect it to fail (meaning that if it succeeded, the test would fail). I
had once created that file on my hard drive by pure coincidence, and so
th
If you have -o and multiple input files, which output file are you
specifying? It seems easier to just say that if multiple input files are
present, the output file names are automatically calculated
On Mon, Dec 3, 2018 at 2:48 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
If that's the case, you specify -mode="compile-and-link" and you can
specify the output. That will work fine. The condition in the code only
checks for -mode='compile'
On Mon, Dec 3, 2018 at 3:38 PM Stella Stamenova
wrote:
> Are there no cases where you want all of the input files to be compil
The idea is that if you specify -mode=compile, then no link happens and the
output is potentially many object files. If there's only one object file,
then we allow the user to specify the name of that output. But if there's
multiple, then it's hard to specify that with a single command line
invoc
Author: zturner
Date: Tue Dec 4 13:48:27 2018
New Revision: 348305
URL: http://llvm.org/viewvc/llvm-project?rev=348305&view=rev
Log:
[build.py] A few general improvements.
This makes -mode=compile support multiple inputs (and hence
multiple outputs).
It also makes the value of -arch for compili
Author: zturner
Date: Tue Dec 4 14:46:01 2018
New Revision: 348314
URL: http://llvm.org/viewvc/llvm-project?rev=348314&view=rev
Log:
Fix LLDB build script.
A local patch was omitted from the original commit. This makes
the tests pass.
Modified:
lldb/trunk/lit/helper/build.py
Modified: lld
Author: zturner
Date: Tue Dec 4 15:56:25 2018
New Revision: 348319
URL: http://llvm.org/viewvc/llvm-project?rev=348319&view=rev
Log:
[build.py] Disable tests on non-Windows.
This won't work until we get the GCC / clang builder implemented.
Modified:
lldb/trunk/lit/BuildScript/modes.test
If you can commit the same fix I did for the other two that would be great,
otherwise I’ll get to it when i get into the office in ~2 hours
On Wed, Dec 5, 2018 at 3:03 AM Pavel Labath wrote:
> On 05/12/2018 00:56, Zachary Turner via lldb-commits wrote:
> > Author: zturner
> > Date
Yes, if the tests pass for you with current builder, please commit
On Wed, Dec 5, 2018 at 6:06 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov added a comment.
>
> It seems that all the reviews this one depends on are already in. Can we
> proceed with it?
It should be, but I haven’t tested any of the non Windows paths at all yet,
so while that seems like a logical fix, there’s probably something else
that would break, like not having a clang-cl environment. So the thinking
was to just disable them until i can implement and test support for other
pla
It is not possible to specify object file name in compile and link mode.
But perhaps we can just change the default object file name to include
something from the output file as well
On Wed, Dec 5, 2018 at 12:26 PM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.ura
I was thinking that we could just automatically compute the output file
names as:
os.path.join(out_dir, basename(output_file) + '.' + basename(input_file) +
'.obj')
Currently it's just
os.path.join(out_dir, basename(input_file) + '.obj')
which is why I think the problem occurs.
On Wed, Dec 5,
Lgtm. Btw I noticed StreamBuffer, which might be another easy one
On Thu, Dec 6, 2018 at 3:27 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath updated this revision to Diff 176948.
> labath added a comment.
>
> That's a good point, thanks for reminding me.
>
> Re-clang-f
Yea that sounds reasonable
On Thu, Dec 6, 2018 at 1:07 AM Pavel Labath wrote:
> On 06/12/2018 09:25, Aleksandr Urakov via lldb-commits wrote:
> >
> > I thought about what Stella have said, and it seems that I have found a
> > good solution for this. We can use something like `tempfile`
> > (https
Author: zturner
Date: Thu Dec 6 08:55:00 2018
New Revision: 348499
URL: http://llvm.org/viewvc/llvm-project?rev=348499&view=rev
Log:
Support skewed stream arrays.
VarStreamArray was built on the assumption that it is backed by a
StreamRef, and offset 0 of that StreamRef is the first byte of the
Author: zturner
Date: Thu Dec 6 09:49:15 2018
New Revision: 348505
URL: http://llvm.org/viewvc/llvm-project?rev=348505&view=rev
Log:
[PDB] Move some code around. NFC.
Added:
lldb/trunk/source/Plugins/SymbolFile/NativePDB/DWARFLocationExpression.cpp
lldb/trunk/source/Plugins/SymbolFile/N
Author: zturner
Date: Thu Dec 6 10:39:58 2018
New Revision: 348511
URL: http://llvm.org/viewvc/llvm-project?rev=348511&view=rev
Log:
[build.py] Embed the output file name in generated object file names.
In compile-and-link mode, the user doesn't specify the name of the
object files to generate,
Hopefully fixed in r348511. I went with the approach of concatenating the
executable file name, for two reasons. First, it's easier, since dealing
with the tmpfile module and mkstemp and sorts has its own set of
complexities and issues. Secondly, because it means the build artifacts
will still b
Author: zturner
Date: Thu Dec 6 10:45:07 2018
New Revision: 348514
URL: http://llvm.org/viewvc/llvm-project?rev=348514&view=rev
Log:
Fix line endings in build.py
Modified:
lldb/trunk/lit/helper/build.py
Modified: lldb/trunk/lit/helper/build.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/
Fwiw, I think mode=compile-and-link and compiler=any are both defaults, so
those 2 options could be omitted to make this shorter. Not a big deal
though
On Thu, Dec 6, 2018 at 3:28 PM Stella Stamenova via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: stella.stamenova
> Date: Thu Dec
Author: zturner
Date: Fri Dec 7 11:34:02 2018
New Revision: 348631
URL: http://llvm.org/viewvc/llvm-project?rev=348631&view=rev
Log:
[NativePDB] Reconstruct function declarations from debug info.
Previously we would create an lldb::Function object for each function
parsed, but we would not add t
Author: zturner
Date: Mon Dec 10 16:15:03 2018
New Revision: 348813
URL: http://llvm.org/viewvc/llvm-project?rev=348813&view=rev
Log:
Fix undefined behavior in Variable.h
m_loc_is_constant_data was uninitialized, so unless someone
explicitly called SetLocIsConstantData(), this would be UB.
I thi
But if the minidump and PDBs are in the same directory, then wouldn't my
proposed solution also work (while also being a permanent solution)?
On Tue, Dec 11, 2018 at 10:47 AM Leonard Mosescu wrote:
> We talked about this offline, but bringing the discussion back here. Can
>> you describe the us
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
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
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
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.
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
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 `
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
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
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
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: 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
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
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
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
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 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
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
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
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:
>
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
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
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
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.
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.
>
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
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
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
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 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: 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: 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: 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 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: 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
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.
>
>
>
>
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
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
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: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: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 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
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
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
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
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
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
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
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
Author: zturner
Date: Mon May 21 12:47:45 2018
New Revision: 332877
URL: http://llvm.org/viewvc/llvm-project?rev=332877&view=rev
Log:
Enable Python API for OpenBSD.
Patch by David Carlier
Modified:
lldb/trunk/scripts/utilsOsType.py
Modified: lldb/trunk/scripts/utilsOsType.py
URL:
http://ll
This change has introduced a dependency from Core -> clang Driver (due to
#include "clang/Driver/Driver.h" in ModuleList.cpp). Can you please try to
find a way to remove this dependency?
On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via lldb-commits
wrote:
> This revision was not a
We've been going to a lot of effort recently to separate out dependencies
and properly layer libraries. Even if we deemed this to be an acceptable
location to #include something from clang/Driver, the CMake does not
actually reference clangDriver in its link list. So the only reason this
is worki
Yea I don’t think this addresses the problem. We should be able to link
against parts of lldb without a dependency on clang. Since this is about
configuring something related to clang, it seems like it should be isolated
to some part of lldb that interfaces with clang
On Tue, May 22, 2018 at 4:32 P
There's not really a diagram, because we don't have an exact vision of what
the final layering is going to look like (some things will need to be split
up, entirely new targets will need to be introduced, etc). Mostly it's
just built from experience based on what the primary logical function of a
SystemInitializerFull.cpp, in the
function SystemInitializerFull::Initialize().
On Wed, May 23, 2018 at 9:44 AM Adrian Prantl wrote:
>
>
> On May 23, 2018, at 8:51 AM, Zachary Turner wrote:
>
> There's not really a diagram, because we don't have an exact vision of
> what the final layering is g
Actually, now I’m starting to wonder why can’t
ClangModulesDeclVendor.cpp just call this function in clangDriver to get
the default if the accessor returns an empty string? That sidesteps all of
this initialization funny business and lets the client just handle it.
Would that work?
On Wed, May
Author: zturner
Date: Wed May 23 16:56:09 2018
New Revision: 333143
URL: http://llvm.org/viewvc/llvm-project?rev=333143&view=rev
Log:
Break dependency from Core to ObjectFileJIT.
The only reason this was here was so that Module could have a
function called CreateJITModule which created things in
Author: zturner
Date: Wed May 23 17:11:24 2018
New Revision: 333145
URL: http://llvm.org/viewvc/llvm-project?rev=333145&view=rev
Log:
Add missing include.
Modified:
lldb/trunk/include/lldb/Core/Module.h
Modified: lldb/trunk/include/lldb/Core/Module.h
URL:
http://llvm.org/viewvc/llvm-project
On Wed, May 23, 2018 at 7:04 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> I worry when concerns of layering which seem a little artificial to me
> would make us add a shadow class for something that is already well
> expressed as it is. If you pa
+1 I’d like to get rid of all EnumerateXXX with callback functions and
replace with iterator based equivalents. Given that in this case the
iterator version already exists, I definitely think we should try to use it
instead
On Wed, May 30, 2018 at 9:30 AM Pavel Labath via Phabricator <
revi...@revi
Author: zturner
Date: Mon Jun 4 10:41:00 2018
New Revision: 333933
URL: http://llvm.org/viewvc/llvm-project?rev=333933&view=rev
Log:
Remove dependency from Host to clang.
Host depended on clang because HostInfo had a function to get
the directory where clang was installed. We move this over to
Do you just need a pdb, or does it really need to be a vs pdb? lld can
generate high quality pdbs now. So it might be possible to use lld to link
and produce a pdb when you run the test.
Pavel’s suggestion is equally viable, you can dump a pdb to yaml and
convert it back to a pdb at test time.
Th
On Thu, Jun 7, 2018 at 2:53 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:
> aleksandr.urakov added a comment.
>
> Yes, it does really need to be a VS PDB. Function-level linking is a
> linker's feature and I can't found support of this feature in lld, so I
> think module a
As a general rule, lld-link is command line compatible with MSVC and
clang-cl is command line compatible with cl. So, the /order option should
work exactly the same with lld-link as it does with link.
On Thu, Jun 7, 2018 at 7:00 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrot
Author: zturner
Date: Thu Jun 7 12:58:58 2018
New Revision: 334221
URL: http://llvm.org/viewvc/llvm-project?rev=334221&view=rev
Log:
[FileSystem] Split up the OpenFlags enumeration.
This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition. The firs
101 - 200 of 2276 matches
Mail list logo
