On Fri, Dec 1, 2017 at 3:50 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> Cool. We do need to make sure people don't start writing tests against it
> yet, however. That would be wasted effort.
>
I don't think it follows that it would be a wasted
vsk created this revision.
Herald added a subscriber: mgorny.
Various part of lldb make use of anonymous structs and unions. In every case
I've seen the usage is idiomatic, and doesn't deserve a warning.
For example, logic in the NSDictionary and NSSet plugins use anonymous structs
in a manner
Yeah, I was not being realistic in saying that.
debugserver has a bunch of junk in it specific to our various embedded
platforms that isn't actually buildable outside of Apple, but which we need
(it's all #ifdef around in the debugserver sources). We aren't going to be
able to do away with thi
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319599: Add a symbols subcommand to lldb-test. (authored by
zturner).
Changed prior to commit:
https://reviews.llvm.org/D40745?vs=125197&id=125239#toc
Repository:
rL LLVM
https://reviews.llvm.org/D4
Author: zturner
Date: Fri Dec 1 16:15:29 2017
New Revision: 319599
URL: http://llvm.org/viewvc/llvm-project?rev=319599&view=rev
Log:
Add a symbols subcommand to lldb-test.
Differential Revision: https://reviews.llvm.org/D40745
Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF
There was also some discussion from some Facebook people about using their
own in-house ds2. It sounds like a large effort, but IIUC it's compatible
with debugserver, and supports more platforms than lldb-server.
+stephane and saleem since they know more about it.
Actually, +greg too since I gue
Author: jingham
Date: Fri Dec 1 16:11:18 2017
New Revision: 319598
URL: http://llvm.org/viewvc/llvm-project?rev=319598&view=rev
Log:
Don't use llvm::EnablePrettyStackTrace on macOS.
LLDB.framework gets loaded into Xcode and other
frameworks, and this is inserting a signal handler into
the proce
If somebody finds themselves ambitious to work on debugserver, they should
divert that energy to porting lldb-server to macOS IMHO.
Jim
> On Dec 1, 2017, at 4:04 PM, Jim Ingham wrote:
>
> Yes, we don't use llvm code in debugserver. It doesn't actually use any lldb
> classes either, it's its
Yes, we don't use llvm code in debugserver. It doesn't actually use any lldb
classes either, it's its own standalone thing.
Jim
> On Dec 1, 2017, at 4:01 PM, Zachary Turner via lldb-commits
> wrote:
>
> I don't recall, is there a hard restriction on debugserver not being allowed
> to use l
I don't recall, is there a hard restriction on debugserver not being
allowed to use llvm code? Because YAML is a superset of JSON
On Fri, Dec 1, 2017 at 3:36 PM Davide Italiano via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Also, FWIW, this is blatantly not the correct way of using ass
Author: vedantk
Date: Fri Dec 1 15:53:01 2017
New Revision: 319597
URL: http://llvm.org/viewvc/llvm-project?rev=319597&view=rev
Log:
Fix warning in DynamicLoaderDarwinKernel.cpp, NFC
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
Modified:
ll
jingham added a comment.
Cool. We do need to make sure people don't start writing tests against it yet,
however. That would be wasted effort.
https://reviews.llvm.org/D40745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.l
zturner added a comment.
In https://reviews.llvm.org/D40745#942913, @jingham wrote:
> I'm sure this is just a "quick and dirty implementation" thing, but depending
> on the output of Dump functions doesn't seem like a great idea for long term
> stable testing.
>
> Those functions are meant to b
jingham added a comment.
I'm sure this is just an "quick and dirty implementation" thing, but depending
on the output of Dump functions doesn't seem like a great idea for long term
stable testing.
Those functions are meant to be useful for debugging lldb, and gathering data
when you can't get
Also, FWIW, this is blatantly not the correct way of using assertions.
It should either be assert(false && "patatino") or the more canonical
llvm_unreachable("patatino").
Relying on the implicit conversion from string to bool seems risky
(and not really useful).
On Fri, Dec 1, 2017 at 3:29 PM, Ved
Author: vedantk
Date: Fri Dec 1 15:29:04 2017
New Revision: 319596
URL: http://llvm.org/viewvc/llvm-project?rev=319596&view=rev
Log:
Fix warnings in JSON.cpp, NFC
These asserts are no-ops, and are supplanted by -Wcovered-switch.
Modified:
lldb/trunk/tools/debugserver/source/JSON.cpp
Modifi
Author: vedantk
Date: Fri Dec 1 15:24:12 2017
New Revision: 319595
URL: http://llvm.org/viewvc/llvm-project?rev=319595&view=rev
Log:
Fix warnings in DNBDataRef.cpp, NFC
Modified:
lldb/trunk/tools/debugserver/source/DNBDataRef.cpp
Modified: lldb/trunk/tools/debugserver/source/DNBDataRef.cpp
vsk added a comment.
The general approach sgtm, and the patch itself looks reasonable.
https://reviews.llvm.org/D40745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
davide added inline comments.
Comment at: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2764-2765
switch (reloc_type(rel)) {
case R_386_32:
case R_386_PC32:
default:
It's unclear to me why PC-rel and 32-bit abs rel are not handl
davide added subscribers: vsk, aprantl.
davide added a comment.
I really like this approach. I think it's going to expose a large amount of
bugs, and probably facilitate the transition in case we want to move to the
LLVM readers for this.
@aprantl / @vsk , what do you think?
https://reviews.ll
zturner added a comment.
If I remove that assert, I get this output:
D:\src\llvmbuild\lldb>bin\lldb-test.exe clang-ast foo.o
error: foo.o {0x003b}: unhandled type tag 0x0005
(DW_TAG_formal_parameter), please file a bug and attach the file at the start
of this error message
error: foo.
zturner created this revision.
Herald added a subscriber: emaste.
This is the bare minimum needed to dump `ClangASTContext`s via `lldb-test`.
Within the first 10 seconds of using this, I already found a bug. A `FIXME`
note and repro is included in the comments in this patch.
With this, it shou
Author: jankratochvil
Date: Fri Dec 1 12:14:09 2017
New Revision: 319580
URL: http://llvm.org/viewvc/llvm-project?rev=319580&view=rev
Log:
Prevent vain lldb::user_id_t 0x lookups
I have found LLDB commonly looks up lldb::user_id_t 0x failing to find
its DIE. One would rather expe
This certainly should be cleared up and centralized. I'm not quite as sure it
should be in Platform however. For instance, macOS has the DebugSymbols
framework that allows users to specify a local lookup tool to find symbol files
given a UUID. That runs only on MacOS and requires MacOS specif
yes, that should work, and we should give it at least a shot :)
On Fri, Dec 1, 2017 at 11:01 AM, Zachary Turner wrote:
> As you said a smaller repro is needed, but I'm imagining a case where we can
> write a file containing some C++ code that uses a template that LLDB doesn't
> understand, compil
As you said a smaller repro is needed, but I'm imagining a case where we
can write a file containing some C++ code that uses a template that LLDB
doesn't understand, compile it with clang to generate some DWARF, and then
run `lldb-test clang-ast a.out`, where the clang-ast subcommand loads the
file
On Fri, Dec 1, 2017 at 10:49 AM, Jim Ingham wrote:
> The failure shows that we don't yet support all template kinds in lldb, and
> that we don't have enough testing for a wide variety of C++ template types.
> Adrian found one instance of this failure, but it is in the Swift compiler so
> I nee
The fact that this passes on macOS likely does mean the general mechanism works
but that the Linux library loading hook gets called too late, so you probably
can't fix it in lldb. Be interesting to see if gdb has the same problem.
Jim
> On Dec 1, 2017, at 3:09 AM, Pavel Labath wrote:
>
> coo
The immediate failure - not checking for NULL from an API that can return NULL
- is more the sort of thing you should enforce in code not by testing, either
by having the API return some kind of empty object that clients can deal with
in a regular way, or by using something like llvm's forced ch
zturner added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:20
+ - Name:.bogus
+# CHECK-NOT: .bogus
+Type:SHT_PROGBITS
labath wrote:
> zturner wrote:
> > labath wrote:
> > > zturner wrote:
> > > > You should probab
labath added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:20
+ - Name:.bogus
+# CHECK-NOT: .bogus
+Type:SHT_PROGBITS
zturner wrote:
> labath wrote:
> > zturner wrote:
> > > You should probably put this as the very
zturner added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:1
+# REQUIRES: zlib
+# RUN: yaml2obj %s > %t
labath wrote:
> zturner wrote:
> > labath wrote:
> > > It's right here. (I'm open to suggestions where to place it).
> > I see. I think p
zturner added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:20
+ - Name:.bogus
+# CHECK-NOT: .bogus
+Type:SHT_PROGBITS
labath wrote:
> zturner wrote:
> > You should probably put this as the very first check stateme
jankratochvil accepted this revision.
jankratochvil added a comment.
This revision is now accepted and ready to land.
On Fedora 27 x86_64 it has no regressions and these results turned
Failure->Success:
LibcxxIteratorDataFormatterTestCase-test_with_run_command_dwarf.log
LibcxxIteratorDataFor
labath created this revision.
Herald added subscribers: JDevlieghere, krytarowski, aprantl, emaste.
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will sometimes not emit debug info for types like
std::string. Whether it does this, and which tests will fail
labath updated this revision to Diff 125110.
labath added a comment.
Rebase on master and update the test.
https://reviews.llvm.org/D40616
Files:
lit/CMakeLists.txt
lit/Modules/compressed-sections.yaml
lit/Modules/lit.local.cfg
lit/lit.cfg
lit/lit.site.cfg.in
source/Plugins/ObjectFi
labath marked 2 inline comments as done.
labath added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:1
+# REQUIRES: zlib
+# RUN: yaml2obj %s > %t
zturner wrote:
> labath wrote:
> > It's right here. (I'm open to suggestions where to place it).
>
On Fri, 01 Dec 2017 13:02:42 +0100, Pavel Labath wrote:
> > I expect because LLDB does not have any Linux DWARF index support, it has
> > only some Apple OSX index support. GDB's `.debug_index` is not usable for
> > LLDB as it does not contain DIE offsets. I would like to implement DWARF-5
> > `.de
Author: labath
Date: Fri Dec 1 04:05:00 2017
New Revision: 319536
URL: http://llvm.org/viewvc/llvm-project?rev=319536&view=rev
Log:
Kill struct IOVEC
struct iovec is used as an interface to system (posix) api's. As such,
we shouldn't be using it in os-independent code, and we shouldn't be
defini
On 30 November 2017 at 20:17, Jan Kratochvil via Phabricator
wrote:
> jankratochvil added a comment.
>
> In https://reviews.llvm.org/D40475#940462, @labath wrote:
>
>> It looks like it could be a fun project to reimplement `dwz` on top of llvm
>> dwarf library, but I understand that would be a co
On 30 November 2017 at 19:10, Zachary Turner via Phabricator
wrote:
> zturner added a comment.
>
> In https://reviews.llvm.org/D40475#935615, @labath wrote:
>
>> The thing to be aware of with this testing strategy is that you will
>> probably be the only person who will be able to run these tests
On 30 November 2017 at 19:08, Jim Ingham wrote:
> We had a similar problem with the tests on macOS. lldb has a facility that
> will do automatic lookup of UUID -> dSYM (macOS's separate debug info format)
> and if you are internal to Apple this will find all the system library debug
> info. T
cool. thanks.
On 30 November 2017 at 20:43, Jim Ingham via lldb-commits
wrote:
> Author: jingham
> Date: Thu Nov 30 12:43:00 2017
> New Revision: 319472
>
> URL: http://llvm.org/viewvc/llvm-project?rev=319472&view=rev
> Log:
> Fix this test so that the breakpoints you set are
> unambiguously on o
43 matches
Mail list logo