zturner added a subscriber: tatyana-krasnukha.
zturner added a comment.
It would be nice if You could replace the logic that iterates these arrays.
We no longer need to terminate on a sentinel nullptr entry and can now use
range based for loop
Repository:
rLLDB LLDB
https://reviews.llvm.org/D
zturner added a comment.
You might be right, I’m on mobile so hard for me to review. I saw a bunch
of nullptr so assumed it was still using sentinel values for iterating. If
not, ignore my suggestion
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52572
___
zturner added a comment.
No, separate revision is fine. Thanks!
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52572
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner added a subscriber: aleksandr.urakov.
zturner added a comment.
It requires a lot of work (nobody has started porting it). lldb-server
exists on other platforms but it basically needs a full port to Windows. It
doesn’t use the same process plugin, but it would instead use a different
plugin
zturner accepted this revision.
zturner added a comment.
Can you change the description of the patch before submitting it? It's hard to
understand why the change does what the description says it does, because the
description mentions 3 types of chars but the patch only handles 1. I would
jus
zturner added a comment.
Couple of options:
1. Can you give an example of before/after output?
2. Is the `size_t` change related?
3. Can you use -U99 in the future when generating patches?
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52627
_
zturner added a comment.
s/options/comments/
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52627
___
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.
BTW, I wrote a demangler for Windows ABI that should be 100% complete modulo
bugs and can generate an AST that RichManglingContext should use. So it would
be interesting if someone decided
zturner added a comment.
I think it’s fine. Eventually when you are ready to support remote
debugging hopefully we can convert it over to using lldb-server
https://reviews.llvm.org/D52618
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
zturner added a comment.
One idea would be to define some lit substitutions like %debuginfo. It’s
true you can produce a gcc style command line that will be equivalent to a
clang-cl invocation but it won’t be easy. eg you’ll needing to pass
-fms-compatibility as well as various -I for includes.
I
zturner added a comment.
In https://reviews.llvm.org/D52618#1251076, @stella.stamenova wrote:
> In https://reviews.llvm.org/D52618#1250909, @zturner wrote:
>
> > One idea would be to define some lit substitutions like %debuginfo. It’s
> > true you can produce a gcc style command line that will b
zturner added a comment.
In https://reviews.llvm.org/D52618#1252372, @labath wrote:
> In https://reviews.llvm.org/D52618#1250909, @zturner wrote:
>
> > One idea would be to define some lit substitutions like %debuginfo. It’s
> > true you can produce a gcc style command line that will be equivale
zturner added a comment.
> By the way, what do you think, how can we make LLDB support aligned stacks?
> As far as I know, similar alignment problems are reproducible on non-Windows
> too.
When you see VFRAME, you need to look in FPO data. As you might have guessed,
VFRAME only occurs in X86.
zturner added a comment.
You didn't include it here, but I notice the test file just writes `clang-cl
/Zi`. Should we be passing `-m32` or `-m64`? Currently, the test just runs
with whatever architecture happens to be set via the VS command prompt. The
behavior here is different on x86 and x
zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.
Nice find, thanks
Repository:
rLLDB LLDB
https://reviews.llvm.org/D53090
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://li
zturner added a comment.
If you plan to invest in more substantial changes in `ObjectFilePECOFF`, it
might worth considering a complete re-write in terms of `llvm::object::coff`.
It has pretty comprehensive support for the PE/COFF spec, so it's just a matter
of implementing `ObjectFilePECOFF`
zturner added inline comments.
Comment at: packages/Python/lldbsuite/test/lldbtest.py:2230-2233
+# In Python 2, communicate sends byte strings. In Python 3,
communicate sends bytes.
+# If we got a string (and not a byte string), encode it before sending.
+
zturner added a subscriber: vsk.
zturner added a comment.
See the other email thread. The bots have been broken since September, all
of them complain about missing FileCheck executable
Repository:
rLLDB LLDB
https://reviews.llvm.org/D50478
___
l
zturner added a subscriber: aprantl.
zturner added a comment.
https://reviews.llvm.org/D53002
Is the thread I'm referring to.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D50478
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http:/
zturner added a subscriber: vsk.
zturner added a comment.
Why is FileCheck missing in the first place?
https://reviews.llvm.org/D53175
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-comm
zturner added a comment.
In https://reviews.llvm.org/D53086#1261697, @aleksandr.urakov wrote:
> Thanks a lot for so detailed answer, it helps!
>
> So we need to parse a FPO program and to convert it in a DWARF expression
> too. The problem here (in the DIA case) is that I don't know how to retri
zturner added a comment.
In https://reviews.llvm.org/D53086#1263001, @zturner wrote:
> In https://reviews.llvm.org/D53086#1261697, @aleksandr.urakov wrote:
>
> > Thanks a lot for so detailed answer, it helps!
> >
> > So we need to parse a FPO program and to convert it in a DWARF expression
> > t
zturner added a comment.
In https://reviews.llvm.org/D52461#1265335, @aleksandr.urakov wrote:
> Hello!
>
> I just have tried to patch `CPlusPlusNameParser` in the way to support MSVC
> demangled names, but there is a problem. `CPlusPlusNameParser` splits an
> incoming name in tokens with `clang
zturner added a subscriber: mgorny.
zturner added a comment.
Lgtm
Repository:
rLLDB LLDB
https://reviews.llvm.org/D53402
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner added a comment.
> PDB has no enough info to restore VBase offsets properly, so we have to read
> real VTable instead.
What's missing that you're unable to restore the VBase offset properly?
Repository:
rLLDB LLDB
https://reviews.llvm.org/D53506
__
zturner added a comment.
In https://reviews.llvm.org/D53506#1270919, @aleksandr.urakov wrote:
> In https://reviews.llvm.org/D53506#1270893, @zturner wrote:
>
> > What's missing that you're unable to restore the VBase offset properly?
>
>
> If I understand correctly, in the PDB there is only info
zturner created this revision.
zturner added reviewers: labath, lemo, aleksandr.urakov, stella.stamenova,
asmith.
Herald added subscribers: arphaman, mgorny.
This is the minimal set of functionality necessary to support type lookup by
name in the native PDB plugin.
For the purposes of testing I
zturner added a subscriber: aleksandr.urakov.
zturner added a comment.
To answer your question, PE/COFF executable symbol tables are basically
empty
Repository:
rLLDB LLDB
https://reviews.llvm.org/D53368
___
lldb-commits mailing list
lldb-commits
zturner added inline comments.
Comment at: lldb/lit/SymbolFile/NativePDB/tag-types.cpp:87
+// Test single inheritance.
+class Derived : public Class {
+public:
lemo wrote:
> - at least one virtual function + override?
> - at least one method returning void?
The r
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB345047: [NativePDB] Add basic support for tag types to
the native pdb plugin. (authored by zturner, committed by ).
Herald added subscribers: teemperor, abidh.
Changed prior to commit:
https://review
zturner created this revision.
zturner added reviewers: labath, davide, clayborg.
Herald added a subscriber: JDevlieghere.
[NFC] Refactor SetBaseClasses and DeleteBaseClasses.
We currently had a 2-step process where we had to call
SetBaseClassesForType and DeleteBaseClasses. Every single
zturner created this revision.
zturner added reviewers: clayborg, jingham, labath.
Herald added subscribers: atanasyan, JDevlieghere, sdardis.
When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`.
We then pass it through all of LLDB this way, as a uint32. This is
unfort
zturner added a comment.
In https://reviews.llvm.org/D53597#1273087, @jingham wrote:
> It would be great not to have to use comments to express what these values
> mean. OTOH, having to put in static casts whenever you want to or values
> together would be a pain, so if there's no way to do it
zturner added inline comments.
Comment at:
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:3273-3274
+ is_virtual, is_base_of_class);
+ if (!result)
+break;
+
If the result is a `nullptr`, then there is no base
zturner added inline comments.
Comment at:
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:3273-3274
+ is_virtual, is_base_of_class);
+ if (!result)
+break;
+
zturner wrote:
> If the result is a `nullptr`, then
zturner updated this revision to Diff 170737.
zturner added a comment.
Remove the reference to `llvm/ADT/BitmaskEnu.h` and define the operators
ourselves. Also, removed a few casts that got left in.
https://reviews.llvm.org/D53597
Files:
lldb/include/lldb/Core/Address.h
lldb/include/lldb/
zturner created this revision.
zturner added reviewers: davide, jingham, clayborg.
Herald added a subscriber: JDevlieghere.
This is a followup to https://reviews.llvm.org/D53597, with 2 more enums.
Assuming that patch is good, I see no reason why this wasn't isn't good as
well, but I'm throwing
zturner added a comment.
In https://reviews.llvm.org/D53094#1273556, @asmith wrote:
> I think this addresses all the previous comments.
Still didn't get a clear answer if the mutex being used needs to be recursive.
If it doesn't, perhaps `std::mutex` can be used instead of
`std::recursive_mu
zturner created this revision.
zturner added reviewers: clayborg, labath, jingham.
Herald added subscribers: JDevlieghere, aprantl.
Previously the Module would parse a type name into scope and base name during a
lookup and only give the SymbolFile plugin the base name, then it would filter
the r
zturner added a comment.
Note that AFAICT, native PDB plugin is now the only plugin where you can do
`type lookup -- NS::Struct::Local` and have it return instantly. On the
regular PDB plugin it doesn't work at all (returns no results). On the DWARF
plugin, I haven't tested, but it will eithe
zturner added a comment.
Hi Greg, any thoughts on this?
https://reviews.llvm.org/D53597
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner added a comment.
In https://reviews.llvm.org/D53662#1275238, @jingham wrote:
> I worry that your patch changes the behavior when you add the type_class
> explicitly in the lookup (i.e. look up "struct Struct" not "Struct". That
> should work...
>
> Note, this doesn't currently work in
zturner added a subscriber: JDevlieghere.
zturner added a comment.
It seems like FileSpec was moved out of Utility and into Host. I’m not a
fan of this change, because it took a lot of effort to get it into Utility,
which helped break a lot of bad dependencies. Can we invert this dependency
and mo
zturner updated this revision to Diff 171134.
zturner added a comment.
Fixed issues pointed out by @jingham and added some test coverage for this.
https://reviews.llvm.org/D53662
Files:
lldb/include/lldb/Core/Module.h
lldb/include/lldb/Symbol/SymbolFile.h
lldb/include/lldb/Symbol/SymbolVe
zturner added a comment.
In https://reviews.llvm.org/D53597#1276086, @clayborg wrote:
> As long as Swig is happy and the ABI doesn't change I am ok with this. Will
> we see the variables better when debugging? Or is this solely so the
> SymbolContextItem type doesn't disappear from the debug in
zturner added a comment.
In https://reviews.llvm.org/D53597#1276110, @zturner wrote:
> In https://reviews.llvm.org/D53597#1276086, @clayborg wrote:
>
> > As long as Swig is happy and the ABI doesn't change I am ok with this. Will
> > we see the variables better when debugging? Or is this solely
zturner added a comment.
In https://reviews.llvm.org/D53597#1276145, @jingham wrote:
> So far as I can tell, this patch will make lookup of exact types faster for
> PDB, but because of the way DWARF debug_names tables are constructed, I don't
> think there's any way we can do the same thing for
zturner added a subscriber: jingham.
zturner added a comment.
I guess the question is, How is that hash and the bucket computed? If it's
based on the full name, then you should be able to get fast exact lookup.
If it's based on the based name, then it will indeed be slow.
https://reviews.llvm.o
zturner added a comment.
I envision `FileSpec` as being more of a `PathSpec`. It should be able
manipulate paths as strings and nothing more. There is indeed some logic that
still remains that resolves paths, but it manages to do this using LLVM's file
system APIs and the only reason it's sti
zturner added a comment.
In https://reviews.llvm.org/D53532#1276463, @JDevlieghere wrote:
> Thanks for the feedback! I totally agree it's a good solution and it was one
> of the things I considered. It didn't make it to the top of the list because
> it is very intrusive and changes the semantic
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB345312: [NFC] Refactor SetBaseClasses and
DeleteBaseClasses. (authored by zturner, committed by ).
Changed prior to co
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB345313: Don't type-erase the SymbolContextItem
enumeration. (authored by zturner, committed by ).
Herald added a subscr
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345313: Don't type-erase the SymbolContextItem
enumeration. (authored by zturner, committed by ).
Herald added subscribers
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345314: Don't type-erase the FunctionNameType or
TypeClass enums. (authored by zturner, committed by ).
Herald added a sub
zturner created this revision.
zturner added reviewers: lemo, aleksandr.urakov, stella.stamenova.
LLDB has the ability to display global variables, even without a running
process, via the `target variable` command. This is because global variables
are linker initialized, so their values are emb
zturner added a comment.
In https://reviews.llvm.org/D53662#1276253, @jingham wrote:
> So the current approach relies on the ability to sniff the name to determine
> the context in which the user intends to find it. It does (and always did)
> use the presence of an initial "::" to tell whether
zturner added a comment.
which generic SymbolFile test do you mean? The lit ones are the only ones that
are set up to run in this particular manner (run lines, check lines, etc), and
currently we don't have a way to run different / multiple command line
invocations. I came up with this test i
zturner added a comment.
In https://reviews.llvm.org/D53731#1276633, @jingham wrote:
> Well, what's really going on is that I'm not familiar enough with lit to know
> that it doesn't have the ability to run different commands to produce the
> input file... But as you guessed, my point is that
zturner added reviewers: vsk, labath.
zturner added a comment.
In https://reviews.llvm.org/D53731#1276660, @jingham wrote:
> Could you also use Vedant's new FileCheck dotest test class? That should
> allow you to write the tests exactly as you are, but use the dotest mechanism
> to build and r
zturner added a comment.
In https://reviews.llvm.org/D53731#1276743, @vsk wrote:
> In https://reviews.llvm.org/D53731#1276732, @zturner wrote:
>
> > In https://reviews.llvm.org/D53731#1276660, @jingham wrote:
> >
> > > Could you also use Vedant's new FileCheck dotest test class? That should
> >
zturner added a comment.
In https://reviews.llvm.org/D53731#1276818, @jingham wrote:
> dotest tests don't require a process. Presumably dotest knows how to build
> windows targeted PDB debug flavor files (to go along with dwarf/dsym/etc.).
> So it would be straightforward to make a test that
zturner added inline comments.
Comment at: lldb/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h:46
+ // due to the debug magic at the beginning of the
stream.
+ uint64_t global : 1; // True if this is from the globals stream.
+ uint64_t modi : 16; // For
zturner added inline comments.
Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:913
+
+ uint32_t section_idx = section - 1;
+ if (section_idx >= section_list->GetSize())
zturner wrote:
> lemo wrote:
> > comment explaining the - 1 ?
>
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345373: [NativePDB] Add the ability to dump dump global
variables. (authored by zturner, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D53731
zturner added a subscriber: aleksandr.urakov.
zturner added a comment.
Ahh, I meant to remind you, because I noticed this when I was looking
through the SymbolFilePDB code recently. I think the LLVM guideline is not
to use so much auto. The generally accepted rule is that we can use for
the resu
zturner added a comment.
For trivial changes it's ok to submit without review. This is true for
cleanup and trivial refactor, but especially for build break like this
one., and even more so if you consider yourself code owner in the
corresponding code area.
Repository:
rLLDB LLDB
https://rev
zturner added a subscriber: aleksandr.urakov.
zturner added a comment.
Lgtm
Repository:
rLLDB LLDB
https://reviews.llvm.org/D53753
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commi
zturner added a subscriber: clayborg.
zturner added a comment.
Ok, that reasoning makes sense, I’ll see what i can do
https://reviews.llvm.org/D53662
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
zturner accepted this revision.
zturner added a comment.
I always wondered if we actually even need methods like this in `FileSystem`
given that they already exist in `llvm::sys::fs`. Is it possible to just call
the llvm methods directly, or is it still helpful to call the ones in
`FileSystem`
zturner added a comment.
Is this still blocked on anything?
https://reviews.llvm.org/D52618
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner added a comment.
I think we should try as hard as possible to have just one way of writing these
tests. So if we know there are going to be two different use cases, one where
we have mutually exclusive variants (e.g. run a process on OSX, Linux,
Windows), and platform agnostic variants
zturner created this revision.
zturner added reviewers: lemo, aleksandr.urakov.
Previous patches added support for dumpign global variables of builtin types,
so this patch does the same for class types.
For the most part, everything just worked, there was only one minor bug fix
needed, which wa
zturner added a comment.
In https://reviews.llvm.org/D53788#1279096, @shafik wrote:
> Are we refactoring in the right place? Why not just refactor
> `FileSpec::GetByteSize()` why is `FileSpec` the wrong place?
There was another review thread where we discussed this just the other day.
Basica
zturner added a comment.
So I started looking into this, and things get tricky. If we're doing a lookup
by fully qualified name, I would expect there to never be more than one match,
but LLDB doesn't seem to hold this same assumption. For example, in
`ItaniumABILanguageRuntime::GetTypeInfoFro
zturner added a comment.
In https://reviews.llvm.org/D53662#1279738, @jingham wrote:
> Exact matches aren't a C++ specific thing. An exact match is useful for
> mixed C/C++ since you might want to say Foo and not Bar::Foo. IIRC a couple
> of the places where exact was dialed up explicitly in
zturner added a comment.
In https://reviews.llvm.org/D53662#1279761, @jingham wrote:
> That depends on the definition of "fully qualified name". If you can ensure
> that it means "name of C++ class" - or other ODR enforcing type system, then
> you could make that assumption. In C you are free
zturner added a comment.
In https://reviews.llvm.org/D53662#1279777, @jingham wrote:
> Yes, that usage is exactly the sort of use I was talking about. When we get
> an ObjC object and want to find its dynamic type, we read the type name by
> following the object's ISA pointer to the Class obje
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345629: [NativePDB] Add support for dumping global variables
of class type. (authored by zturner, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.o
zturner added a comment.
In https://reviews.llvm.org/D52461#1280527, @aleksandr.urakov wrote:
> Update the diff according to the discussion, making it possible to parse MSVC
> demangled names by `CPlusPlusLanguage`. The old PDB plugin still uses
> `MSVCUndecoratedNameParser` directly because:
>
zturner created this revision.
zturner added reviewers: aleksandr.urakov, lemo.
This adds basic support for getting function signature types
into LLDB's type system, including into clang's AST. There are
a few edge cases which are not correctly handled, mostly dealing
with nested classes,
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345848: [NativePDB] Get LLDB types from PDB function types.
(authored by zturner, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D53951?vs=172
zturner created this revision.
zturner added a reviewer: jingham.
char16, char32, and wchar_t were previously broken. If you had a simple
variable like `wchar_t x = L'1'` and wrote `p x` LLDB would output `(wchar_t) x
= 1\0`. This is because it was using `eFormatChar` with a size of 2. What w
zturner added a comment.
No, but thanks for the pointer. Interestingly, it worked for me on my home
machine but not on my work machine, and I'm not sure what the difference
between the two is.
Clearly the test in lang/cpp/wchar_t is making it into
`lldb_private::formatters::WCharSummaryProvid
zturner added a comment.
Update: It's because There was a problem with my `PYTHONPATH` and python was
getting disabled at CMake configure time. So I was effectively running with
`LLDB_DISABLE_PYTHON`. So basically it's only broke on the
`LLDB_DISABLE_PYTHON` codepath.
https://reviews.llvm.o
zturner added a comment.
Side question, should we just kill the `LLDB_DISABLE_PYTHON=0` codepath? It
can be a headache to get LLDB linking with Python (particularly on Windows),
but it would be nice to be able to delete all the preprocessor stuff.
https://reviews.llvm.org/D53989
__
zturner created this revision.
zturner added reviewers: stella.stamenova, labath, beanz, davide.
Herald added subscribers: jfb, delcypher, mgorny, ki.stfu.
A year or so ago, I re-wrote most of the lit infrastructure in LLVM so that it
wasn't so boilerplate-y. I added lots of common helper type s
zturner added a comment.
In https://reviews.llvm.org/D54009#1284827, @stella.stamenova wrote:
> Looks good. The formatting in lit.cfg.py is a bit messy (indentations,
> especially), but as long as the tests pass, this is an improvement :). Thanks!
Is there something like clang-format for Pytho
zturner added a subscriber: aleksandr.urakov.
zturner added a comment.
Lgtm
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54031
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commi
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB346008: Refactor the lit configuration files (authored by
zturner, committed by ).
Herald added subscribers: teemperor, abidh.
Changed prior to commit:
https://reviews.llvm.org/D54009?vs=172254&id=17
zturner added a comment.
This function is called in `SymbolFile/NativePDB` as well.
https://reviews.llvm.org/D54003
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner created this revision.
zturner added reviewers: aleksandr.urakov, labath, lemo.
Herald added subscribers: erik.pilkington, mgorny.
Previously we were not able to accurately represent tag record types with clang
record decls. The primary reason for this is that for type information PDB
o
zturner added a subscriber: stella.stamenova.
zturner added a comment.
Fix incoming, sorry about that.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/
zturner added a comment.
In https://reviews.llvm.org/D54053#1286272, @lemo wrote:
> nice!
AFAIU this is just the "default" access of the class. I should probably
investigate why it's needed in the first place, since it can be deduced from
the tag type.
https://reviews.llvm.org/D54053
__
zturner added a comment.
I actually found some issues with this, or at least some potential issues which
I'm not sure are actual issues. But I'm adding some new functionality to LLDB
to help me confirm whether these are real issues or not, and worst case
scenario it will open up some new testi
zturner created this revision.
zturner added reviewers: vsk, davide, labath, jingham, aleksandr.urakov,
clayborg.
Herald added subscribers: JDevlieghere, aprantl.
This can be useful when diagnosing AST related problems. For example, I had a
bug where I was accidentally creating a record type mu
zturner updated this revision to Diff 172510.
zturner added a comment.
clang dumps to stderr. Only use color if stderr supports this (e.g. if it's
not redirected to a file).
https://reviews.llvm.org/D54072
Files:
lldb/include/lldb/Symbol/SymbolFile.h
lldb/source/Commands/CommandObjectTarg
zturner updated this revision to Diff 172511.
zturner added a comment.
I just added a new test which dumps the clang AST and makes sure no bogus
records get introduced. Since this is already LGTM'ed I'm assuming this is
good to go, but since it now depends on https://reviews.llvm.org/D54072, I
zturner added a comment.
Bleh, I think I found a problem with this approach. Since we assume everything
is a namespace, it can lead to ambiguities. I think we need to actually
consult the debug info while parsing components of the mangled name. For
example, suppose you have this code:
nam
zturner added a subscriber: vsk.
zturner added a comment.
Unfortunately then color output is impossible. Where else would the output
be expected to go?
https://reviews.llvm.org/D54072
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://
zturner added a subscriber: davide.
zturner added a comment.
Ok so probably this commands output will not go to a log file when logging
is enabled? I can’t think of any other side effects.
Given that the immediate use case for this is interactive investigation and
testing, the first of which is h
1 - 100 of 733 matches
Mail list logo
