labath added a comment.
I also think it we should try to keep FileSpec in the Utility module. We should
be able to do that by deleting the "utility" functions in the FileSpec class,
and updating everything to go through the FileSystem class.
After the VFS introduction, something like `file_spec
Author: aleksandr.urakov
Date: Thu Oct 25 01:27:42 2018
New Revision: 345247
URL: http://llvm.org/viewvc/llvm-project?rev=345247&view=rev
Log:
[API] Extend the `SBThreadPlan` interface
Summary:
This patch extends the `SBThreadPlan` to allow retrieving of thread plans
for scripted steps.
Reviewer
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345247: [API] Extend the `SBThreadPlan` interface (authored
by aleksandr.urakov, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D53361?vs=1708
Author: grimar
Date: Thu Oct 25 02:22:26 2018
New Revision: 345249
URL: http://llvm.org/viewvc/llvm-project?rev=345249&view=rev
Log:
[LLDB] - Parse the DW_LLE_startx_length correctly for DWARF v5 case.
Currently, we always parse the length field of DW_LLE_startx_length entry as
U32.
That is corr
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB345249: [LLDB] - Parse the DW_LLE_startx_length correctly
for DWARF v5 case. (authored by grimar, committed by ).
Herald added a subscriber: lldb-commits.
Repository:
rLLDB LLDB
https://reviews.llvm
aleksandr.urakov marked 5 inline comments as done.
aleksandr.urakov added a comment.
Ah, yes, sure! It's my mistake. I didn't pay attention to the fact that a
symtab owns symbols. I'll update the patch, thanks!
Comment at: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp:1344-1
aleksandr.urakov updated this revision to Diff 171056.
aleksandr.urakov marked 3 inline comments as done.
https://reviews.llvm.org/D53368
Files:
include/lldb/Symbol/SymbolFile.h
include/lldb/Symbol/SymbolVendor.h
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
source/Plugins/SymbolFile/PD
Author: grimar
Date: Thu Oct 25 03:25:45 2018
New Revision: 345251
URL: http://llvm.org/viewvc/llvm-project?rev=345251&view=rev
Log:
Recommit r345127 "[LLDB] - Add support for DW_RLE_base_address and
DW_RLE_offset_pair entries (.debug_rnglists)"
With the fix: do not forget to hanlde the DW_RLE_s
Author: adrian
Date: Thu Oct 25 08:30:43 2018
New Revision: 345274
URL: http://llvm.org/viewvc/llvm-project?rev=345274&view=rev
Log:
Fix a bug PlatformDarwin::SDKSupportsModule.
This fixes a bug PlatformDarwin::SDKSupportsModule introduced by
https://reviews.llvm.org/D47889. VersionTuple::tryPar
shafik added inline comments.
Comment at: source/Plugins/Platform/MacOSX/PlatformDarwin.cpp:1405
-llvm::StringRef version_part;
-
-if (sdk_name.startswith(sdk_strings[(int)desired_type])) {
- version_part =
- sdk_name.drop_front(strlen(sdk_strings[(int)des
aprantl created this revision.
aprantl added a reviewer: shafik.
This addresses review feedback from https://reviews.llvm.org/D53677.
https://reviews.llvm.org/D53709
Files:
source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
source/Plugins/Platform/MacOSX/PlatformDarwin.h
Index: source/Plug
shafik added a comment.
LGTM
https://reviews.llvm.org/D53709
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: adrian
Date: Thu Oct 25 09:15:17 2018
New Revision: 345278
URL: http://llvm.org/viewvc/llvm-project?rev=345278&view=rev
Log:
Get rid of casts. (NFC)
Differential Revision: https://reviews.llvm.org/D53709
Modified:
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345278: Get rid of casts. (NFC) (authored by adrian,
committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D53709?vs=171117&id=171119#toc
Repository
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
clayborg added a comment.
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 info?
https://reviews.llvm.org/D53597
__
Author: adrian
Date: Thu Oct 25 10:36:05 2018
New Revision: 345287
URL: http://llvm.org/viewvc/llvm-project?rev=345287&view=rev
Log:
Remove accidentally committed duplicate code
Modified:
lldb/trunk/source/Utility/ArchSpec.cpp
Modified: lldb/trunk/source/Utility/ArchSpec.cpp
URL:
http://llv
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Very close, just down to making the SymbolVendor::GetSymtab() call
symtab.CalculateSymbolSizes() and symtab.Finalize().
Comment at: source/Plugins/SymbolFile/P
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
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
This looks good to me.
Looking at the addition of Type::ConsumeTypeClass makes it really clear that
both this function and Type::GetTypeScopeAndBasename need to dispatch to the
CompilerSyst
davide added inline comments.
Comment at:
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp:213-229
+ // Handle variables with incomplete array types.
+ auto *type = in_value.GetCompilerType().GetOpaqueQualType();
+ auto qual_type = clang::Qual
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 DWARF.
But unless I'm misunderstanding the patch, this doesn't change correctness of
the l
jingham added subscribers: clayborg, zturner.
jingham added a comment.
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 DWARF.
But unless I
aleksandr.urakov added a comment.
Yes, I'll implement it tomorrow (I'm already OOO now), thanks. But is it really
necessary to check the number of symbols added if we must to calculate /
finalize the symtab after getting it from object file anyway? May be just
always do it after creation and pr
clayborg added a comment.
The current SymbolFile::FindTypes(...) in was designed with type base name only
due to how DWARF stores it variables. It has a "const CompilerDeclContext
*parent_decl_ctx" which can be specified in order to limit what we find. So we
might be able to think of this as a
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
clayborg added a comment.
In https://reviews.llvm.org/D53368#1276152, @aleksandr.urakov wrote:
> Yes, I'll implement it tomorrow (I'm already OOO now), thanks. But is it
> really necessary to check the number of symbols added if we must to calculate
> / finalize the symtab after getting it from
Ah, right... Too many patches (a good problem!)
The standard as I read it says that the name entry points into the general
string table, but doesn't specify which entry it points to. However, the
current DWARF debug_info doesn't ever emit a string for the fully qualified
name, so you would ha
jingham added a comment.
Ah, right... Too many patches (a good problem!)
The standard as I read it says that the name entry points into the general
string table, but doesn't specify which entry it points to. However, the
current DWARF debug_info doesn't ever emit a string for the fully qualif
JDevlieghere added a comment.
While I don't disagree with the proposed approach, it needs to be highlighted
that extracting all file system operations would be very intrusive.
- Almost all logic in FileSpec deals with the filesystem. You can't even
resolve a path without it. How do you imagine
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
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.
On Thu, Oct 25, 2018 at 11:33 AM Jim Ingham via Phabricator via
lldb-commits wrote:
jingham added a comment.
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 a symbol is exact. That's
obviously also inappropriate for a gen
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
I am pretty sure the has is computed from the name string. And BTW, having the
base name in the quick lookup tables (either with or alongside the full name)
is a really good thing. People using the debugger really don't want to type
out fully qualified names as a general rule. So you have to
Yes, it's an interesting dichotomy how the two formats have evolved. PDB
was designed with IDEs in mind so it's optimized around exact matches. For
example, you press a key on a specific line of code. Nobody ever is
entering commands to do fuzzy lookups based on base names, so this was
never rea
gdb's expression parser went out of it's way to allow you to type as little as
possible, and to do things that made no sense in the current context (use
variables and types in expressions that aren't actually visible in the current
context, etc). People's workflows came to really depend on thes
JDevlieghere added a comment.
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 semantics of FileSpec quite a bit (i.e. it
becomes a PathSpec as Zachary n
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
Author: zturner
Date: Thu Oct 25 13:44:56 2018
New Revision: 345312
URL: http://llvm.org/viewvc/llvm-project?rev=345312&view=rev
Log:
[NFC] Refactor SetBaseClasses and DeleteBaseClasses.
We currently had a 2-step process where we had to call
SetBaseClassesForType and DeleteBaseClasses. Every sin
Author: zturner
Date: Thu Oct 25 13:45:19 2018
New Revision: 345313
URL: http://llvm.org/viewvc/llvm-project?rev=345313&view=rev
Log:
Don't type-erase the SymbolContextItem enumeration.
When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of L
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
Author: zturner
Date: Thu Oct 25 13:45:40 2018
New Revision: 345314
URL: http://llvm.org/viewvc/llvm-project?rev=345314&view=rev
Log:
Don't type-erase the FunctionNameType or TypeClass enums.
This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be stron
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
jingham added a comment.
Is there anything PDB specific about the test you've added? If not, it might
be good to use this as a generic SymbolFile test.
https://reviews.llvm.org/D53731
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http:
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
jingham added a comment.
It seemed to me like Greg thought you were changing the behavior of lookups,
which this patch doesn't do, it just makes it more efficient. I don't know if
that alters his objections or not.
The Module and higher layer of FindTypes calls are awkward. For instance
Modu
jingham added a comment.
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 you have written a bunch of tests
that would be valuable to test a
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
jingham added a comment.
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 run the example.
https://reviews.llvm.org/D53731
___
lldb
lemo accepted this revision.
lemo added a comment.
This revision is now accepted and ready to land.
looks good. a few comments inline.
Comment at: lldb/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h:46
+ // due to the debug magic at the beginning of the
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
vsk added a comment.
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
> > allow you to write the tests exactly as you are, but use the dotest
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
> >
Author: jdevlieghere
Date: Thu Oct 25 17:00:17 2018
New Revision: 345346
URL: http://llvm.org/viewvc/llvm-project?rev=345346&view=rev
Log:
Add functionality to export settings
For the reproducer feature I need to be able to export and import the
current LLDB configuration. To realize this I've ex
This revision was automatically updated to reflect the committed changes.
Closed by commit rL345346: Add functionality to export settings (authored by
JDevlieghere, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D52651?vs=170258&id=171
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB345346: Add functionality to export settings (authored by
JDevlieghere, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D52651?vs=170258&id=171231#toc
Repository:
rLLDB LLDB
htt
jingham added a comment.
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 had your input sources, built
and made a target out of it and then
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
Author: jdevlieghere
Date: Thu Oct 25 17:39:27 2018
New Revision: 345350
URL: http://llvm.org/viewvc/llvm-project?rev=345350&view=rev
Log:
Remove test that checks auto-completion for settings set.
With the new `-f` option for `settings set`, `-` (dash) no longer
auto-complete to `-g`.
Modified:
jingham added a comment.
The first of the commands you showed presents info we definitely should add to
type lookup. I actually have a bug around to do that, but it hasn't risen to
the top of my queue because it's trivial to do with the SB API's so every time
I've needed that info I get it fro
Thanks for fixing the bots!
On Thu, Oct 25, 2018 at 5:41 PM Jonas Devlieghere via lldb-commits
wrote:
>
> Author: jdevlieghere
> Date: Thu Oct 25 17:39:27 2018
> New Revision: 345350
>
> URL: http://llvm.org/viewvc/llvm-project?rev=345350&view=rev
> Log:
> Remove test that checks auto-completion f
Author: jdevlieghere
Date: Thu Oct 25 17:50:54 2018
New Revision: 345351
URL: http://llvm.org/viewvc/llvm-project?rev=345351&view=rev
Log:
Update test that checks auto-completion for settings set.
This reverts r345350 and updates the test rather than removing it. Now
we check that `--g` auto-comp
68 matches
Mail list logo
