Author: mehdi_amini
Date: Fri Jun 23 13:20:13 2017
New Revision: 306134
URL: http://llvm.org/viewvc/llvm-project?rev=306134&view=rev
Log:
Fix typo: using && instead of & when evaluating a mask
Summary: Reported by coverity, I don't know how to provide a test.
Reviewers: zturner
Subscribers: lld
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
If the CIEs can change per CIE,l then this patch is fine.
Comment at: include/lldb/Symbol/DWARFCallFrameInfo.h:38
DWARFCallFrameInfo(ObjectFile &objfile, lldb::Section
zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.
Nice, yea this will be a big help I think.
https://reviews.llvm.org/D34400
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lis
labath updated this revision to Diff 103976.
labath added a comment.
Herald added a subscriber: emaste.
Well, PluginProcessPOSIX does not seem to be using anything from Core directly,
although I doubt that is thanks to this patch. It will be a long time before
anything stops depending on Core (my
labath added a comment.
In https://reviews.llvm.org/D34613#790745, @clayborg wrote:
> Glad this is happening. Does this mean we won't see the "bad eh frame"
> warnings anymore on linux? See inlined comments.
Unfortunately, I doubt it. This does nothing about eh_frame parsing, it just
adds deb
labath updated this revision to Diff 103971.
labath added a comment.
This is how things would look like if we move Connection to Utility instead. I
needed to do two things to make this happen:
- Keep Connection::CreateDefaultConnection in Host (now known as
Host::CreateDefaultConnection), becaus
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Glad this is happening. Does this mean we won't see the "bad eh frame" warnings
anymore on linux? See inlined comments.
Comment at: include/lldb/Symbol/DWARFCa
Can you run the analyze deps script before and after this patch, and update
the cmake files if any deps are no longer necessary?
On Mon, Jun 26, 2017 at 8:24 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
> Herald added subscribers: mgorny, kubam
ravitheja added a comment.
In https://reviews.llvm.org/D33674#790653, @labath wrote:
> In https://reviews.llvm.org/D33674#790595, @ravitheja wrote:
>
> > Yes you can start looking at it. The thing with munmap stuff is the
> > following, you basically don't want to give the user an opportunity to
ravitheja added a comment.
>> Regarding the testing strategy, we have tests at two levels, one at the SB
>> API level and the other at the tool level.
>
> Cool, are you going to put some of those tests in this patch?
The problem with uploading tests is that they need minimum Broadwell machine
labath created this revision.
Herald added subscribers: mgorny, kubamracek.
It had a dependency on StringConvert and file reading code, which is not
in Utility. I've replaced that code by equivalent llvm operations.
I've added a unit test to demonstrate that parsing a file still works.
https://
labath added a comment.
In https://reviews.llvm.org/D33674#790595, @ravitheja wrote:
> Yes you can start looking at it. The thing with munmap stuff is the
> following, you basically don't want to give the user an opportunity to have
> an uninitialized or instances which have been destroyed but
ravitheja added inline comments.
Comment at: source/Plugins/Process/Linux/ProcessorTrace.cpp:393
+ llvm::SmallVector, 2> parts = {
+ src.slice(src_cyc_index), src.drop_back(src.size() - src_cyc_index)};
+
labath wrote:
> Isn't the drop-back expression equiv
ravitheja added a comment.
Yes you can start looking at it. The thing with munmap stuff is the following,
you basically don't want to give the user an opportunity to have an
uninitialized or instances which have been destroyed but not deleted.
So I removed the Destroy function from the public sp
labath added a comment.
Should I start looking at this or you have more changes planned? I still see
manual memory management in the Destroy function...
BTW, what's your testing strategy for this?
Comment at: source/Plugins/Process/Linux/ProcessorTrace.cpp:393
+ llvm::SmallV
tatyana-krasnukha added a comment.
Works well for me. Thank you a lot for bringing it up to scratch!
https://reviews.llvm.org/D34613
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commit
ravitheja updated this revision to Diff 103943.
ravitheja marked 6 inline comments as done.
ravitheja added a comment.
More changes from past feedback.
https://reviews.llvm.org/D33674
Files:
include/lldb/Host/common/NativeProcessProtocol.h
include/lldb/Host/linux/Support.h
source/Host/lin
labath added a comment.
Hi Abhishek,
Thank you for incorporating the changes. I still see some room for improvement
in the cmake files. I realize that this is something most people are not
familiar with, and is not exactly glamorous work, but it's still part of our
codebase and we should make
abhishek.aggarwal updated this revision to Diff 103924.
abhishek.aggarwal added a comment.
Changes after feedback
- Created static libs for each hardware feature to combine it to generate
single shared library
- Removed error codes decoding logic and directly using error strings
https://review
abhishek.aggarwal added a comment.
Hi Pavel .. My comments are inlined. Please let me know if you have more
concerns. I am submitting the patch with all the proposed changes.
Comment at: tools/intel-features/CMakeLists.txt:50
+install(TARGETS lldbIntelFeatures
+ LIBRARY DESTI
labath created this revision.
Herald added subscribers: aprantl, mgorny.
This is a beefed-up version of https://reviews.llvm.org/D33504, which adds
support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a pe
Author: labath
Date: Mon Jun 26 01:13:22 2017
New Revision: 306278
URL: http://llvm.org/viewvc/llvm-project?rev=306278&view=rev
Log:
Shorten sanitizer plugin names
Summary:
The new UndefinedBehaviorSanitizer plugin was breaking file path length
limits, because it's (fairly long name) appears mult
22 matches
Mail list logo
