zturner created this revision.
Herald added subscribers: krytarowski, mgorny, srhines.
This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB. I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319402: refactor: Simplify loop with
DWARFCompileUnit::Extract (authored by jankratochvil).
Changed prior to commit:
https://reviews.llvm.org/D40635?vs=124871&id=124872#toc
Repository:
rL LLVM
https
Author: jankratochvil
Date: Wed Nov 29 21:49:02 2017
New Revision: 319402
URL: http://llvm.org/viewvc/llvm-project?rev=319402&view=rev
Log:
refactor: Simplify loop with DWARFCompileUnit::Extract
Forgotten small simplification in D40212.
Differential revision: https://reviews.llvm.org/D40635
Mod
jankratochvil created this revision.
Herald added a subscriber: JDevlieghere.
Forgotten small simplification in https://reviews.llvm.org/D40212.
https://reviews.llvm.org/D40635
Files:
source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
Index: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cp
And of course, one such discipline would be "only use SB API's"...
Jim
> On Nov 29, 2017, at 5:00 PM, Jim Ingham wrote:
>
> I thought we weren't talking about why you want this lldb-test, but rather
> why tests that poke deep into the lldb_private API's are or are not
> appropriate for your
I thought we weren't talking about why you want this lldb-test, but rather why
tests that poke deep into the lldb_private API's are or are not appropriate for
your test dingus.
The thing I worry about is if you start using this for very special purpose
"reach deep into the lldb_private API's"
Many reasons.
1) a test that looks like this:
```
RUN: yaml2obj %p/Inputs/compressed-section.yaml > %t/compressed-section.obj
RUN: lldb-test %s | FileCheck %s
create-module -f %t/compressed-section.obj
dump-module-sections compressed-section.obj
; CHECK: Section: .hello_elf
; CHECK-NEXT: Size:
Author: jingham
Date: Wed Nov 29 16:23:42 2017
New Revision: 319389
URL: http://llvm.org/viewvc/llvm-project?rev=319389&view=rev
Log:
Fix the gtest target for the move of ArchSpecTest.cpp from Core to Utility.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xc
> On Nov 29, 2017, at 3:46 PM, Zachary Turner wrote:
>
> FWIW, it can certainly use the SB API where it makes sense, but I think
> requiring that it only use the SB API would be very limiting and a big
> mistake.
>
> The entire point of a tool such as this is that it allows you to dig deep
FWIW, it can certainly use the SB API where it makes sense, but I think
requiring that it only use the SB API would be very limiting and a big
mistake.
The entire point of a tool such as this is that it allows you to dig deep
into internals that would be difficult to access otherwise.
On Wed, Nov
> On Nov 29, 2017, at 2:51 PM, Zachary Turner via lldb-commits
> wrote:
>
>
>
> On Wed, Nov 29, 2017 at 1:59 PM Jim Ingham wrote:
> I'm mostly basing this concern on the bad effect this had on gdb all of whose
> testing was expect based command scraping. gdb is a tool that's much closer
On Wed, Nov 29, 2017 at 1:59 PM Jim Ingham wrote:
> I'm mostly basing this concern on the bad effect this had on gdb all of
> whose testing was expect based command scraping. gdb is a tool that's much
> closer to lldb than any of the compiler tools so that experience seems
> relevant. It's been
> On Nov 29, 2017, at 2:13 PM, Greg Clayton wrote:
>
>
>> On Nov 29, 2017, at 2:10 PM, Jason Molenda via lldb-commits
>> wrote:
>>
>> The last time this discussion came up (Sep 2016), I pointed out that a great
>> approach here would be to use the lldb-mi driver. The MI (Machine
>> Inter
> On Nov 29, 2017, at 2:10 PM, Jason Molenda via lldb-commits
> wrote:
>
> The last time this discussion came up (Sep 2016), I pointed out that a great
> approach here would be to use the lldb-mi driver. The MI (Machine Interface)
> is a JSON-like debugger UI which closely models how people
The last time this discussion came up (Sep 2016), I pointed out that a great
approach here would be to use the lldb-mi driver. The MI (Machine Interface)
is a JSON-like debugger UI which closely models how people use the lldb command
line driver. It was written at Cygnus (long before JSON, hen
jankratochvil marked an inline comment as done.
jankratochvil added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:216
+ DWARFCompileUnitData *m_data;
+
clayborg wrote:
> jankratochvil wrote:
> > clayborg wrote:
> > > Is there
I'm mostly basing this concern on the bad effect this had on gdb all of whose
testing was expect based command scraping. gdb is a tool that's much closer to
lldb than any of the compiler tools so that experience seems relevant. It's
been a decade or so since I worked on gdb, but back when I wa
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Please undo all renaming from offset to file_offset. The "offset" you get from
a DIE should always be the absolute .debug_info offset. No need to say
file_offset. Patch will be
On Wed, Nov 29, 2017 at 1:38 PM, Jim Ingham wrote:
> I'm a little confused by your response.
>
> My stated objection to command output dependent tests is and has always been
> that they make the test dependent on the details of command output. Over
> time doing so makes it hard to modify comman
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Take a look how the LLVM DWARF parser handles its units. It makes a DWARFUnit
base class that the compile unit inherits from. That can then be used for type
units and compile uni
I'm a little confused by your response.
My stated objection to command output dependent tests is and has always been
that they make the test dependent on the details of command output. Over time
doing so makes it hard to modify command output. This is sort of related to
interactivity, in th
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319359: refactor: Unify+simplify DWARFCompileUnit
ctor+Clear() into in-class… (authored by jankratochvil).
Changed prior to commit:
https://reviews.llvm.org/D40212?vs=124290&id=124806#toc
Repository:
Author: jankratochvil
Date: Wed Nov 29 13:13:11 2017
New Revision: 319359
URL: http://llvm.org/viewvc/llvm-project?rev=319359&view=rev
Log:
refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class
initializers + Extract()
It has no functionality effect.
I was concerned about the wor
jankratochvil added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp:248-249
-while (cu->Extract(dwarf2Data->get_debug_info_data(), &offset)) {
+for (;;) {
+ DWARFCompileUnitSP cu = DWARFCompileUnit::Extract(dwarf2Data, &offset);
+
jankratochvil updated this revision to Diff 124803.
jankratochvil marked an inline comment as done.
jankratochvil added a comment.
Removed excessive: #include:
https://reviews.llvm.org/D40467
Files:
include/lldb/Expression/DWARFExpression.h
source/Expression/DWARFExpression.cpp
source/Pl
jankratochvil marked an inline comment as done.
jankratochvil added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h:15
#include
+#include
clayborg wrote:
> Why is this added here? Doesn't seem to be needed, or it should be moved
jankratochvil marked an inline comment as done.
jankratochvil added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:216
+ DWARFCompileUnitData *m_data;
+
clayborg wrote:
> Is there a reason this is a member variable that I am no
We’ve had this discussion several times, but at the end of the day nothing
has really changed with the larger llvm project having adopted this model
and having spent significant effort in moving forward with it.
Normally, the reason we don't use this model for LLDB tests is because they
require in
jingham added a comment.
It does look a little weird as a unit test, but to me this is mostly because it
would been much simpler to write it as a regular SB API test.
Anyway, I really don't want the details of the text output of lldb commands to
become API. Our experience with gdb was that ove
davide added a comment.
Another very good reason for writing a `FileCheck` test rather than a unittest
is that writing unittest is tedious :)
In particular for new contributors, FileCheck tests are much easier to write
and in this case testing the API surface doesn't seem to add much value.
ht
davide requested changes to this revision.
davide added a comment.
This revision now requires changes to proceed.
This one is a little weird when written as unittest. Not the worst thing, but I
agree it should use `llvm-lit`.
Can you give it a shot, Pavel? If that doesn't work, we should at least
zturner added a comment.
Note that there's no interactivity here. This is "feed some input, get some
output, make sure the output is correct". That's exactly what FileCheck is
designed for. This isn't even testing the public API, it's testing the private
API. We should prefer testing the ac
zturner added a comment.
For the same reason that the entire rest of the LLVM project and all other
subprojects do it, when it makes sense and the nature of the test lends itself
to it.
https://reviews.llvm.org/D40616
___
lldb-commits mailing list
clayborg added a comment.
Why would we text scrape when we can test the API?
https://reviews.llvm.org/D40616
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
zturner added a comment.
It's too bad this has to be written as a unit test, because this would be the
perfect candidate for a FileCheck style test.
Probably a long shot, but have you tried the llvm-lit project? Last time I
tried it, it basically worked, but there were only a handful of tests
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Few nits, but nothing that would hold up the patch. Looks good.
Comment at: include/lldb/Symbol/CompilerType.h:294
+ struct IntegralTemplateArgument;
+
---
labath created this revision.
Herald added subscribers: aprantl, mgorny, emaste.
We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables
us to read data from debug info sections, which are sometimes compressed,
particuarly in the split-dwarf case. This functionality is on
labath created this revision.
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.
Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is in
fjricci added inline comments.
Comment at: source/Host/common/TaskPool.cpp:55
+ static const unsigned g_hardware_concurrency =
+std::max(1u, std::thread::hardware_concurrency());
+ return g_hardware_concurrency;
Is 1 the best default here when hardware_con
On 28 November 2017 at 17:28, Zachary Turner via lldb-commits
wrote:
>
>
> On Tue, Nov 28, 2017 at 2:48 AM Pavel Labath via Phabricator via
> lldb-commits wrote:
>>
>> labath added a comment.
>>
>> On 28 November 2017 at 06:12, Zachary Turner via lldb-commits
>> wrote:
>>
>> > yaml2core would be
labath added a comment.
Looks good, thanks.
Repository:
rL LLVM
https://reviews.llvm.org/D40587
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
41 matches
Mail list logo
