It looks like the macos testsuite on the bot is broken with this -
http://lab.llvm.org:8080/green/view/LLDB/job/lldb/3086/
On my desktop with a recent clang, it works fine. But it seems like every
test? most tests? are failing with
error: parsing line table prologue at 0x (parsing end
clayborg added a comment.
Looks fine to me, but a test would be nice as Zach suggested. I am guessing
before we made way too many sections. Should be easy to conjure up a test and
verify the same sections is used.
https://reviews.llvm.org/D40869
_
zturner added a comment.
This could be tested by using `lldb-test` to dump the section cache and running
`FileCheck` on it to make sure that all expected sections are cached.
https://reviews.llvm.org/D40869
___
lldb-commits mailing list
lldb-commit
xiaobai created this revision.
Herald added a subscriber: emaste.
I recently ran into a shared object that had a reasonably large number
of absolute symbols. Parsing all the symbols in the shared object took an
unusually long amount of time, so I looked into it and found that when we
created fake
vsk updated this revision to Diff 125639.
vsk edited the summary of this revision.
vsk added a comment.
- Address Greg's comments.
https://reviews.llvm.org/D40821
Files:
source/Plugins/Process/Utility/RegisterContextMach_arm.cpp
source/Plugins/Process/Utility/RegisterContextMach_i386.cpp
Ok, cool!
On Tue, Dec 5, 2017 at 2:24 PM Shoaib Meenai wrote:
> Oh, I thought you meant specifically on a Windows build machine, not just
> targeting Windows. I've already submitted it, but I can do some more
> testing locally as well (and I can always revert if anything seems broken).
> With tha
Oh, I thought you meant specifically on a Windows build machine, not just
targeting Windows. I've already submitted it, but I can do some more testing
locally as well (and I can always revert if anything seems broken). With that
said, http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015/b
Oh come now, we have cross-compilation ;-)
That said, I'd like to try this out locally before you submit, but it might
be tomorrow.
On Tue, Dec 5, 2017 at 2:19 PM Shoaib Meenai wrote:
> I didn't, because I didn't have easy access to a Windows LLVM setup (I
> need to get that working again). I d
I didn't, because I didn't have easy access to a Windows LLVM setup (I need to
get that working again). I don't see a reason for many platform-specific
differences here, but I am monitoring the bots closely to make sure nothing
breaks.
From: Zachary Turner
Date: Tuesday, December 5, 2017 at 2:
Can you / did you try this on Windows? I don't see any reason why it
wouldn't work, but I remember having difficulty with all this CMake some
time ago.
On Tue, Dec 5, 2017 at 1:50 PM Shoaib Meenai via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: smeenai
> Date: Tue Dec 5 13:49:5
Author: smeenai
Date: Tue Dec 5 13:49:56 2017
New Revision: 319840
URL: http://llvm.org/viewvc/llvm-project?rev=319840&view=rev
Log:
[CMake] Use PRIVATE in target_link_libraries for executables
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBL
Author: davide
Date: Tue Dec 5 12:55:36 2017
New Revision: 319832
URL: http://llvm.org/viewvc/llvm-project?rev=319832&view=rev
Log:
[Darwin] Delete dead code. NFCI.
Modified:
lldb/trunk/source/Plugins/Process/Darwin/NativeProcessDarwin.h
Modified: lldb/trunk/source/Plugins/Process/Darwin/Na
clayborg added a comment.
In https://reviews.llvm.org/D40821#945379, @vsk wrote:
> In https://reviews.llvm.org/D40821#945314, @clayborg wrote:
>
> > Seems wrong to remove the const on structs that don't need to change in
> > order to make the write happen. Can't we just quiet the warnings with a
vsk added a comment.
In https://reviews.llvm.org/D40821#945314, @clayborg wrote:
> Seems wrong to remove the const on structs that don't need to change in order
> to make the write happen. Can't we just quiet the warnings with a const_cast
> inside the function call?
Absolutely. I opted for d
clayborg added a comment.
Seems wrong to remove the const on structs that don't need to change in order
to make the write happen. Can't we just quiet the warnings with a const_cast
inside the function call?
https://reviews.llvm.org/D40821
___
lldb
Didn't someone recently submit a patch to allow relocation of .o files? That
should have taken care of the issue, no?
> On Dec 4, 2017, at 5:01 AM, Pavel Labath via lldb-commits
> wrote:
>
> The reason you hit the assert there, is because you're running lldb on
> an un-linked object file. When
clayborg added a comment.
One really nice way we can get a lot of testing of the DWARF to
clang::ASTContext conversion is to:
1 - compile a source file with clang and dumps the AST for a specific type as
the compiler knows it
2 - using the .o file with debug info from step 1, load it into LLDB a
labath accepted this revision.
labath added a comment.
In https://reviews.llvm.org/D40757#944293, @vsk wrote:
> I'd like to make this a narrower change as well, but unfortunately, I haven't
> found a way to add in extra CXX flags through the add_library or
> llvm_add_library utilities. Somebody
18 matches
Mail list logo
