Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.
valentinagiusti updated this revision to Diff 70507.
valentinagiusti added a comment.
Improved TestMPXRegisters.py and Makefile according to review.
https://reviews.llvm.org/D24255
Files:
packages/Python/lldbsuite/test/functionalities/register/Makefile
packages/Python/lldbsuite/test/functionalities/register/TestRegisters.py
packages/Python/lldbsuite/test/functionalities/register/a.cpp
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
packages/Python/lldbsuite/test/functionalities/register/main.cpp
packages/Python/lldbsuite/test/functionalities/register/register_command/Makefile
packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py
packages/Python/lldbsuite/test/functionalities/register/register_command/a.cpp
packages/Python/lldbsuite/test/functionalities/register/register_command/main.cpp
source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp
source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
source/Plugins/Process/Utility/RegisterContext_x86.h
source/Plugins/Process/Utility/RegisterInfos_i386.h
source/Plugins/Process/Utility/RegisterInfos_x86_64.h
source/Plugins/Process/Utility/lldb-x86-register-enums.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -610,6 +610,7 @@
.Case("vector-sint32", eFormatVectorOfSInt32)
.Case("vector-uint32", eFormatVectorOfUInt32)
.Case("vector-float32", eFormatVectorOfFloat32)
+ .Case("vector-uint64", eFormatVectorOfUInt64)
.Case("vector-uint128", eFormatVectorOfUInt128)
.Default(eFormatInvalid);
}
@@ -4545,6 +4546,8 @@
reg_info.format = eFormatVectorOfUInt32;
else if (value == "vector-float32")
reg_info.format = eFormatVectorOfFloat32;
+else if (value == "vector-uint64")
+reg_info.format = eFormatVectorOfUInt64;
else if (value == "vector-uint128")
reg_info.format = eFormatVectorOfUInt128;
}
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1566,6 +1566,7 @@
case eFormatVectorOfSInt32: response.PutCString ("format:vector-sint32;"); break;
case eFormatVectorOfUInt32: response.PutCString ("format:vector-uint32;"); break;
case eFormatVectorOfFloat32: response.PutCString ("format:vector-float32;"); break;
+case eFormatVectorOfUInt64: response.PutCString ("format:vector-uint64;"); break;
case eFormatVectorOfUInt128: response.PutCString ("format:vector-uint128;"); break;
default: break;
};
Index: source/Plugins/Process/Utility/lldb-x86-register-enums.h
===
--- source/Plugins/Process/Utility/lldb-x86-register-enums.h
+++ source/Plugins/Process/Utility/lldb-x86-register-enums.h
@@ -106,6 +106,18 @@
lldb_ymm7_i386,
k_last_avx_i386 = lldb_ymm7_i386,
+k_first_mpxr_i386,
+lldb_bnd0_i386 = k_first_mpxr_i386,
+lldb_bnd1_i386,
+lldb_bnd2_i386,
+lldb_bnd3_i386,
+k_last_mpxr = lldb_bnd3_i386,
+
+k_first_mpxc_i386,
+lldb_bndcfgu_i386 = k_first_mpxc_i386,
+lldb_bndstatus_i386,
+k_last_mpxc_i386 = lldb_bndstatus_i386,
+
lldb_dr0_i386,
lldb_dr1_i386,
lldb_dr2_i386,
@@ -119,7 +131,8 @@
k_num_gpr_registers_i386 = k_last_gpr_i386 - k_first_gpr_i386 + 1,
k_num_fpr_registers_i386 = k_last_fpr_i386 - k_first_fpr_i386 + 1,
k_num_avx_registers_i386 = k_last_avx_i386 - k_first_avx_i386 + 1,
-k_num_user_registers_i386 = k_num_gpr_registers_i386 + k_num_fpr_registers_i386 + k_num_avx_registers_i386,
+k_num_mpx_registers_i386 = k_last_mpxc_i386 - k_first_mp
[Lldb-commits] [lldb] r280793 - Fix unittest compilation on windows
Author: labath
Date: Wed Sep 7 03:46:50 2016
New Revision: 280793
URL: http://llvm.org/viewvc/llvm-project?rev=280793&view=rev
Log:
Fix unittest compilation on windows
After the reformat, the unittests do not compile due to missing due to
redefinition errors
between PosixApi.h and ucrt/direct.h. This is a bit of a shot in the dark, as I
have not tested
it on windows, but I am restoring the original include order, so it should
hopefully fix it.
Modified:
lldb/trunk/unittests/Host/SymbolsTest.cpp
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
Modified: lldb/trunk/unittests/Host/SymbolsTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/SymbolsTest.cpp?rev=280793&r1=280792&r2=280793&view=diff
==
--- lldb/trunk/unittests/Host/SymbolsTest.cpp (original)
+++ lldb/trunk/unittests/Host/SymbolsTest.cpp Wed Sep 7 03:46:50 2016
@@ -7,9 +7,10 @@
//
//===--===//
+#include "gtest/gtest.h"
+
#include "lldb/Host/Symbols.h"
#include "lldb/Core/ModuleSpec.h"
-#include "gtest/gtest.h"
using namespace lldb_private;
Modified: lldb/trunk/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp?rev=280793&r1=280792&r2=280793&view=diff
==
--- lldb/trunk/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
(original)
+++ lldb/trunk/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp Wed Sep
7 03:46:50 2016
@@ -16,7 +16,6 @@
#include
#include "GDBRemoteTestUtils.h"
-#include "gtest/gtest.h"
#include "Plugins/Process/Utility/LinuxSignals.h"
#include "Plugins/Process/gdb-remote/GDBRemoteClientBase.h"
Modified:
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp?rev=280793&r1=280792&r2=280793&view=diff
==
---
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
(original)
+++
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
Wed Sep 7 03:46:50 2016
@@ -16,7 +16,6 @@
#include
#include "GDBRemoteTestUtils.h"
-#include "gtest/gtest.h"
#include "Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h"
#include "lldb/Core/DataBuffer.h"
Modified: lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.h?rev=280793&r1=280792&r2=280793&view=diff
==
--- lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.h (original)
+++ lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.h Wed Sep 7
03:46:50 2016
@@ -9,9 +9,10 @@
#ifndef lldb_unittests_Process_gdb_remote_GDBRemoteTestUtils_h
#define lldb_unittests_Process_gdb_remote_GDBRemoteTestUtils_h
-#include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
#include "gtest/gtest.h"
+#include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
+
namespace lldb_private {
namespace process_gdb_remote {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24251: LLDB: API for Permission of object file's sections
abhishek.aggarwal updated this revision to Diff 70513.
abhishek.aggarwal added a comment.
Changes based on review
- Added header doc and ran clang-format on code
https://reviews.llvm.org/D24251
Files:
include/lldb/API/SBSection.h
scripts/interface/SBSection.i
source/API/SBSection.cpp
Index: source/API/SBSection.cpp
===
--- source/API/SBSection.cpp
+++ source/API/SBSection.cpp
@@ -251,6 +251,15 @@
}
uint32_t
+SBSection::GetPermissions() const
+{
+SectionSP section_sp(GetSP());
+if (section_sp.get())
+return section_sp->GetPermissions();
+return 0;
+}
+
+uint32_t
SBSection::GetTargetByteSize ()
{
SectionSP section_sp (GetSP());
Index: scripts/interface/SBSection.i
===
--- scripts/interface/SBSection.i
+++ scripts/interface/SBSection.i
@@ -90,6 +90,9 @@
SectionType
GetSectionType ();
+uint32_t
+GetPermissions() const;
+
%feature("docstring", "
//--
/// Return the size of a target's byte represented by this section
Index: include/lldb/API/SBSection.h
===
--- include/lldb/API/SBSection.h
+++ include/lldb/API/SBSection.h
@@ -72,6 +72,21 @@
GetSectionType ();
//--
+/// Gets the permissions (RWX) of the section of the object file
+///
+/// Returns a mask of bits of enum lldb::Permissions for this section.
+/// Sections for which permissions are not defined, 0 is returned for
+/// them. The binary representation of this value corresponds to [XRW]
+/// i.e. for a section having read and execute permissions, the value
+/// returned is 6
+///
+/// @return
+/// Returns an unsigned value for Permissions for the section.
+//--
+uint32_t
+GetPermissions() const;
+
+//--
/// Return the size of a target's byte represented by this section
/// in numbers of host bytes. Note that certain architectures have
/// varying minimum addressable unit (i.e. byte) size for their
Index: source/API/SBSection.cpp
===
--- source/API/SBSection.cpp
+++ source/API/SBSection.cpp
@@ -251,6 +251,15 @@
}
uint32_t
+SBSection::GetPermissions() const
+{
+SectionSP section_sp(GetSP());
+if (section_sp.get())
+return section_sp->GetPermissions();
+return 0;
+}
+
+uint32_t
SBSection::GetTargetByteSize ()
{
SectionSP section_sp (GetSP());
Index: scripts/interface/SBSection.i
===
--- scripts/interface/SBSection.i
+++ scripts/interface/SBSection.i
@@ -90,6 +90,9 @@
SectionType
GetSectionType ();
+uint32_t
+GetPermissions() const;
+
%feature("docstring", "
//--
/// Return the size of a target's byte represented by this section
Index: include/lldb/API/SBSection.h
===
--- include/lldb/API/SBSection.h
+++ include/lldb/API/SBSection.h
@@ -72,6 +72,21 @@
GetSectionType ();
//--
+/// Gets the permissions (RWX) of the section of the object file
+///
+/// Returns a mask of bits of enum lldb::Permissions for this section.
+/// Sections for which permissions are not defined, 0 is returned for
+/// them. The binary representation of this value corresponds to [XRW]
+/// i.e. for a section having read and execute permissions, the value
+/// returned is 6
+///
+/// @return
+/// Returns an unsigned value for Permissions for the section.
+//--
+uint32_t
+GetPermissions() const;
+
+//--
/// Return the size of a target's byte represented by this section
/// in numbers of host bytes. Note that certain architectures have
/// varying minimum addressable unit (i.e. byte) size for their
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24187: Intel(R) Memory Protection Extensions (Intel(R) MPX) support.
labath added a comment. Thank you for addressing the comments. let's continue this in the other thread. Comment at: packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/TestMPXRegisters.py:27 @@ +26,3 @@ + +@skipIfiOSSimulator +@skipIf(compiler="clang") valentinagiusti wrote: > labath wrote: > > Do we really need the ios simulator decorator here? > Is this naturally skipped if all OSs are skipped except for linux? I am pretty sure it is, I have never needed to use the decorator, although it still exists in some legacy tests. Repository: rL LLVM https://reviews.llvm.org/D24187 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.
labath added inline comments. Comment at: packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:5 @@ +4,3 @@ + +ifeq "$(ARCH)" "i386" + CXXFLAGS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32 valentinagiusti wrote: > labath wrote: > > This should not be necessary. Makefile.rules already correctly appends -m32 > > when needed. Maybe CFLAGS_EXTRAS would work instead (?) > Unfortunately it doesn't append -m32 to all the instances when also a linker > is needed in the build process. In fact, in the test logs it shows that only > the first call of the g++ command has such a flag, and therefore the inferior > code build ends with an error. > If there is a better way to do the same with CFLAGS_EXTRAS please let me know! > I don't see how that is possible. I just made the following test: ``` $ cat Makefile LEVEL = ../../../make CXX_SOURCES := main.cpp CFLAGS_EXTRAS += -Wzero-as-null-pointer-constant include $(LEVEL)/Makefile.rules $ make g++ -std=c++11 -g -O0 -fno-builtin -m64 -Wzero-as-null-pointer-constant -I/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/test_common.h -c -o main.o main.cpp g++ main.o -g -O0 -fno-builtin -m64 -Wzero-as-null-pointer-constant -I/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/test_common.h -o "a.out" $ make ARCH=i386 g++ -std=c++11 -g -O0 -fno-builtin -m32 -Wzero-as-null-pointer-constant -I/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/test_common.h -c -o main.o main.cpp g++ main.o -g -O0 -fno-builtin -m32 -Wzero-as-null-pointer-constant -I/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/make/test_common.h -o "a.out" ``` As you see CFLAGS_EXTRAS was added to both compiler and linker command lines for both 32-bit and 64-bit cases (so, setting LD_EXTRAS is not necessary). Also, Makefile.rules already correctly appended the correct -m32/64 switch to all compiler and linker executions (so, you should not need to set it yourself). If this does not work for you, then we need to figure out why and fix it. I don't believe we should be adding complex rules to these Makefiles, as it increases the maintenance burden down the line. Comment at: packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py:297 @@ -294,4 +296,3 @@ for registerSet in registerSets: -if 'advanced vector extensions' in registerSet.GetName().lower(): -has_avx = True -break +if registerSet.GetName(): +if 'advanced vector extensions' in registerSet.GetName().lower(): valentinagiusti wrote: > labath wrote: > > Do we want to allow a register set with no name? It looks like the root of > > the problem is elsewhere. > These lines of code are just to detect if there are AVX or MPX register sets, > so I don't think there is the need to do anything about nameless sets here. > If you don't like this solution, I think an alternative is to just check if > there are the register names that belong to one set or the other, it just > takes a bit longer - or I could just look for the first register in the set. I was referring to the addition of the `if registerSet.GetName()` pre-check. I know in the previous version of the commit this test failed here due to register set name being `None`. So this also implicitly checked that each register set has a name. Now, you've circumvented that check. This seems to be unnecessary because the test passes even when I remove that, so I think we should do that. I think it's a reasonable expectation that each register set has a name. https://reviews.llvm.org/D24255 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.
valentinagiusti marked an inline comment as done. Comment at: packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:6 @@ +5,3 @@ +ifeq "$(ARCH)" "i386" + CFLAGS_EXTRAS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32 + LD_EXTRAS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32 You are right, if I use CFLAGS_EXTRAS I don't have to check for the arch or use LD_EXTRAS. I wish I knew this from the beginning... https://reviews.llvm.org/D24255 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
emaste added a subscriber: emaste. emaste added a comment. Which library contains `llvm::itaniumDemangle`? https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
On 7 September 2016 at 11:35, Chaoren Lin wrote: > chaoren added a comment. > > Cool. Would it be a good idea to only use LLVM's demangler? We can get rid of > all the messy ifdef business, and I assume the LLVM demangler would be better > maintained and more up to date than any system demangler. Maybe, but it is probably better to do that in a followup patch, no? Cheers, Rafael ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
On 7 September 2016 at 10:41, Ed Maste wrote: > emaste added a subscriber: emaste. > emaste added a comment. > > Which library contains `llvm::itaniumDemangle`? lib/Demangle. I will try to make sue a shared library build works and update the thread. Cheers, Rafael ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24236: gdb-remote: Add jModulesInfo packet
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Sounds good. As long as we know what is there (the XML and Jason's other packet) and know that the desired functionalities do not overlap I am fine with the approach that you suggest! Thanks for looking into it and making sure we don't duplicate functionality. https://reviews.llvm.org/D24236 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. We need to carefully benchmark any changes in demangling if we are thinking about switching to using llvm::itaniumDemangle() for everything. The demangler that was built into libcxxabi was 4 times slower than our fast version. I am not sure what version is now in LLVM, but I would guess that it might be the same version? FastDemangle is fast and any changes can't regress on performance. https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24236: gdb-remote: Add jModulesInfo packet
labath added a comment. Ok, after a bit more digging, this is what I have found: > Error ProcessGDBRemote::GetLoadedModuleList (LoadedModuleInfoList & list); > This packet is not usable **in it's current form** as it does not include the UUID of the module. As far as I can tell, it is intended to provide the information present in the dynamic linker's rendezvous structure, which is something that we retrieve using memory reads at the moment (POSIX-DYLD plugin has support for the packet, but lldb-server does not implement it). It would probably be possible to extend that packet to include the UUID, but that would not be competely trivial as it would require the reimplementation of a large part (the one that reads out the rendezvous structure) of the POSIX-DYLD plugin on the server side. This is something we may want to do eventually, as reading out of the rendezvous structure (it's a linked list) is also quite slow, but it is not the bottleneck at the moment. So I am a bit reluctant to tie these two things together, as this is a big win already. > jGetLoadedDynamicLibrariesInfos This looks like a mac-specific version of the previous packet. It does include the UUID, but it also includes some mac-specific fields I don't need. It also has the same issue that it would require the remote side to traverse the rendezvous structure to retrieve the list of libraries. Given the choice between these two packets, I'd go with extending the first one, as POSIX-DYLD plugin already has some support for the "libraries-svr4" packet. In a way, the packet I am introducing is not really comparable the these two packets. It queries the UUID based on file name, which is an operation which does not even require a running process, whereas the previous two packets deal with reading out the loaded modules from an existing process - it's basically a batch version of the qModuleInfo packet - it's only connection to the dynamic linker is that the dynamic linker knows the names of the modules we will query. (BTW, is the qModuleInfo packet used on darwin targets?) So, my proposal would be the following: keep this packet as-is (it contains no platform-specific info, so it can be used elsewhere in similar ways that qModuleInfo is), and if we do implement server-side rendezvous structure parsing, then we can remove this packet (assuming to new uses for it have been invented). What do you think? https://reviews.llvm.org/D24236 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
zturner added a subscriber: zturner. zturner added a comment. AFAICT, this patch only changes the case where we were already not able to use the fast demangler. So nothing should change. https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
chaoren added a comment. Cool. Would it be a good idea to only use LLVM's demangler? We can get rid of all the messy ifdef business, and I assume the LLVM demangler would be better maintained and more up to date than any system demangler. https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
clayborg added a comment. In https://reviews.llvm.org/D24293#535928, @zturner wrote: > AFAICT, this patch only changes the case where we were already not able to > use the fast demangler. So nothing should change. Yep, I saw that and that is why I OK'ed the patch. Someone else suggested cutting over to only use llvm::itaniumDemangle(), so thus my comment. https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
rafael closed this revision. rafael added a comment. 280821 https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24255: Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.
labath added a comment. I think we're approaching the end now. If you could upload the new version (you'll have to reformat the changes), I'll give it a final pass. Comment at: packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/Makefile:6 @@ +5,3 @@ +ifeq "$(ARCH)" "i386" + CFLAGS_EXTRAS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32 + LD_EXTRAS += -mmpx -fcheck-pointer-bounds -fuse-ld=bfd -m32 valentinagiusti wrote: > You are right, if I use CFLAGS_EXTRAS I don't have to check for the arch or > use LD_EXTRAS. I wish I knew this from the beginning... Yeah, I don't blame you. :) The test suite is not an easy thing to wrap your head around. I am sorry if some of my comments sounded a bit harsh. https://reviews.llvm.org/D24255 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24293: Use llvm's demangler
k8stone added a comment. Glad to see this change. Maintaining another copy of the same demangler in LLDB is definitely unnecessary. https://reviews.llvm.org/D24293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24251: LLDB: API for Permission of object file's sections
Eugene.Zelenko added inline comments. Comment at: source/API/SBSection.cpp:257 @@ +256,3 @@ +SectionSP section_sp(GetSP()); +if (section_sp.get()) +return section_sp->GetPermissions(); You don't need to use get(), because smart pointers have http://en.cppreference.com/w/cpp/memory/shared_ptr/operator_bool. Will be good idea to remove it in other conditions in this file. https://reviews.llvm.org/D24251 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D24304: Braindump of what an LLDB lit test might look like
zturner created this revision.
zturner added subscribers: LLDB, lldb-commits, rnk.
I was trying to brainstorm what a real test that currently exists might look
like if converted to a lit-style test. Not even proposing we do this, just
figured I would throw up what I came up with in case anyone wants to see
something concrete. These tests come from lang/cpp/namespace. There is one
`.test` file for each method in each existing `.py` file. This way everything
gets run in parallel. A couple observations and musings:
1. There is NO MAKEFILE. Usually this is going to be fine, as most Makefiles
are trivial anyway and do nothing. If we wanted to take this idea further so
that it works for our entire test suite, we would need a way to provide custom
build settings. I envision happening through directives in each test file but
there are some issues obviously. We'd have to figure it out.
2. There are no skip / xfail directives. Again, we could design our own
per-file directives for this.
3. There's no manual invocation of the Python APIs. I actually think this is
an advantage. It makes the tests easier to understand. Whether this is
flexible enough to support everything that LLDB tests do is an open question.
We could always provide a `#script ` directive and then embed some
Python code below if we need to do something funky.
4. The checks and directives are interspersed with the code. I think this
makes it much easier to look at a test and digest what it does rather than
having to click through many different files. Although sometimes a test is
specifically testing something that has to do with multiple object files. I
didn't try to address that here, but again, with the freedom to design whatever
set of directives we need to, I think it's doable.
5. Source code is reproduced in every file. This means every test will be
compiling its own target. But in practice I think this will still be a speedup
over our current state of affairs, where every test STILL recompiles its own
target, but it does so serially. In the solution here, at least the compiler
would be run in parallel for each test.
Again, this is just some very early high-level thoughts about what a test might
look like. I mostly approached this from the angle of "what would allow this
test to be the easiest to write and easiest to understand".
https://reviews.llvm.org/D24304
Files:
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/breakpoints_a_func_full.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/breakpoints_func_auto.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/breakpoints_func_full.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/file_scope_lookup_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/function_scope_lookup_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_after_using_declaration_lookup_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_after_using_directive_lookup_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_ambiguity_after_using_lookup_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_lookup_before_using_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_lookup_shadowed_by_using_with_run_cmd.test
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_lookup_with_run_cmd.test
Index:
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_lookup_with_run_cmd.test
===
--- /dev/null
+++
packages/Python/lldbsuite/test/lang/cpp/namespace_lit/scope_lookup_with_run_cmd.test
@@ -0,0 +1,63 @@
+; int func() { return 42; }
+; namespace A {
+; int func(int N) { return N + 3; }
+; int func2() { return 42; }
+; namespace B {
+; int func() { return 4; }
+; }
+; }
+;
+; void exec() {
+; #breakpoint
+; #verify("expr -- func()", start="(int) [[%PH%]] = 1")
+; #verify("expr -- A::B::func()", start="(int) [[%PH%]] = 4")
+; #verify("expr -- func(10)", start="(int) [[%PH%]] = 11")
+; #verify("expr -- ::func()", start="(int) [[%PH%]] = 1")
+; #verify("expr -- A::foo()", start="(int) [[%PH%]] = 42")
+; #continue
+; }
+; namespace A {
+; void exec() {
+; #breakpoint
+; #verify("expr -- func(10)", start="(int) [[%PH%]] = 13")
+; #verify("expr -- B::func()", start="(int) [[%PH%]] = 4")
+; #verify("expr -- func()", start="(int) [[%PH%]] = 3")
+; #continue
+; }
+; namespace B {
+; void exec() {
+; #breakpoint
+; #verify("expr -- func()", start="(int) $8 = 4")
+; #verify("expr -- A::func()", start="(int) $9 = 3")
+; #verify("expr -- func(10)", start="(int) $10 = 13")
+; #continue
+; }
+; void exec2() {
+; using A::func;
+; #breakpoint
+; #verify("expr -- A::func(10)", start="(int) $11 = 13")
+; #conti
[Lldb-commits] [lldb] r280879 - Remove CxaDemangle.cpp / .h from xcode project file.
Author: jmolenda
Date: Wed Sep 7 18:08:36 2016
New Revision: 280879
URL: http://llvm.org/viewvc/llvm-project?rev=280879&view=rev
Log:
Remove CxaDemangle.cpp / .h from xcode project file.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=280879&r1=280878&r2=280879&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Sep 7 18:08:36 2016
@@ -193,7 +193,6 @@
260CC65415D0440D002BF2E0 /* OptionValueUUID.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 260CC64715D0440D002BF2E0 /* OptionValueUUID.cpp
*/; };
260E07C6136FA69E00CF21D3 /* OptionGroupUUID.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 260E07C5136FA69E00CF21D3 /* OptionGroupUUID.cpp
*/; };
260E07C8136FAB9200CF21D3 /* OptionGroupFile.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 260E07C7136FAB9200CF21D3 /* OptionGroupFile.cpp
*/; };
- 2613F6C81B17B82F00D4DB85 /* CxaDemangle.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 2613F6C71B17B82F00D4DB85 /* CxaDemangle.cpp */;
};
26151DC31B41E4A200FF7F1C /* SharingPtr.h in Headers */ = {isa =
PBXBuildFile; fileRef = 261B5A5311C3F2AD00AABD0A /* SharingPtr.h */; settings =
{ATTRIBUTES = (Public, ); }; };
261744781168585B005ADD65 /* SBType.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 261744771168585B005ADD65 /* SBType.cpp */; };
2617447A11685869005ADD65 /* SBType.h in Headers */ = {isa =
PBXBuildFile; fileRef = 2617447911685869005ADD65 /* SBType.h */; settings =
{ATTRIBUTES = (Public, ); }; };
@@ -1562,8 +1561,6 @@
2611FF11142D83060017FEA3 /* SBType.i */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.c.preprocessed; path =
SBType.i; sourceTree = ""; };
2611FF12142D83060017FEA3 /* SBValue.i */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.c.preprocessed; path =
SBValue.i; sourceTree = ""; };
2611FF13142D83060017FEA3 /* SBValueList.i */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.c.preprocessed; path =
SBValueList.i; sourceTree = ""; };
- 2613F6C71B17B82F00D4DB85 /* CxaDemangle.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = CxaDemangle.cpp; path = source/Core/CxaDemangle.cpp; sourceTree =
""; };
- 2613F6C91B17B84500D4DB85 /* CxaDemangle.h */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = CxaDemangle.h;
path = include/lldb/Core/CxaDemangle.h; sourceTree = ""; };
2613F6CA1B17B85400D4DB85 /* FastDemangle.h */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = FastDemangle.h;
path = include/lldb/Core/FastDemangle.h; sourceTree = ""; };
2615DB841208A9C90021781D /* StopInfo.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name =
StopInfo.h; path = include/lldb/Target/StopInfo.h; sourceTree = ""; };
2615DB861208A9E40021781D /* StopInfo.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = StopInfo.cpp; path = source/Target/StopInfo.cpp; sourceTree = "";
};
@@ -4652,8 +4649,6 @@
266603C91345B5A8004DA8B6 /*
ConnectionSharedMemory.cpp */,
26BC7D7C10F1B77400F91463 /* ConstString.h */,
26BC7E9410F1B85900F91463 /* ConstString.cpp */,
- 2613F6C91B17B84500D4DB85 /* CxaDemangle.h */,
- 2613F6C71B17B82F00D4DB85 /* CxaDemangle.cpp */,
26BC7D5910F1B77400F91463 /* DataBuffer.h */,
26BC7D5B10F1B77400F91463 /* DataBufferHeap.h */,
26BC7E7210F1B85900F91463 /* DataBufferHeap.cpp
*/,
@@ -7305,7 +7300,6 @@
268900CF13353E5F00698AC0 /*
SymbolVendorMacOSX.cpp in Sources */,
268900D013353E6F00698AC0 /* Block.cpp in
Sources */,
268900D113353E6F00698AC0 /* ClangASTContext.cpp
in Sources */,
- 2613F6C81B17B82F00D4DB85 /* CxaDemangle.cpp in
Sources */,
265192C61BA8E905002F08F6 /* CompilerDecl.cpp in
Sources */,
268900D213353E6F00698AC0 /* CompilerType.cpp in
Sources */,
945261C11B9A11FC00BF138D /*
LibCxxInitializerList.cpp in Sources */,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-comm
[Lldb-commits] [lldb] r280892 - Remove lldb coding conventions as they are no longer relevant.
Author: jingham Date: Wed Sep 7 19:42:02 2016 New Revision: 280892 URL: http://llvm.org/viewvc/llvm-project?rev=280892&view=rev Log: Remove lldb coding conventions as they are no longer relevant. Removed: lldb/trunk/www/lldb-coding-conventions.html Modified: lldb/trunk/www/sidebar.incl lldb/trunk/www/source.html Removed: lldb/trunk/www/lldb-coding-conventions.html URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/lldb-coding-conventions.html?rev=280891&view=auto == --- lldb/trunk/www/lldb-coding-conventions.html (original) +++ lldb/trunk/www/lldb-coding-conventions.html (removed) @@ -1,152 +0,0 @@ -http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> -http://www.w3.org/1999/xhtml";> - - - -LLDB Tutorial - - - - - The LLDB Coding Conventions - - - - - - - - LLDB Coding Conventions - - - - The LLDB coding conventions differ in a few important respects from LLVM. - - -Note that http://clang.llvm.org/docs/ClangFormat.html";>clang-format will deal with -most of this for you, as such is suggested to run on patches before uploading. Note however that -clang-format is not smart enough to detect instances of humans intentionally trying to line variables -up on a particular column boundary, and it will reformat them to remove this "extraneous" whitespace. -While this is usually the correct behavior, LLDB does have many uses of manually aligned types and -fields, so please be aware of this behavior of clang-format when editing this type of code. - - -Important: Where not explicitly outlined below, assume that the -http://llvm.org/docs/CodingStandards.html";>LLVM Coding Conventions are to be followed. - - Include Order: - LLDB follows http://llvm.org/docs/CodingStandards.html#include-style";>LLVM's include order, -with an addition for LLDB specific headers. - - -Main Module Header -Local/Private Headers -lldb/... -llvm/... -System #includes - - If you encounter existing code that does not follow this ordering, it should not be -taken as an indication that it is ok to not use it. Instead, the surrounding ordering -should be fixed gradually and incrementally. - Source code width: - lldb does not follow the 80 character line restriction llvm imposes. In our -experience, trying to fit C++ code into an 80 character line results in code that -is awkward to read, and the time spent trying to find good indentation points to -avoid this would be much better spent on thinking about your code. - - More importantly, the restriction induces coders to choose overly abbreviated names -to make them better fit in 80 characters. In our opinion choosing good descriptive -names is much more important than fitting in 80 characters. - - In lldb the limit for code lines is 120 characters because it gets awkward to scan - longer lines even on a fairly big monitor, and we've found at that length you seldom - have to make code look ugly to get it to wrap. - - However you will see some instances of longer lines. The most common occurrence is in -the options tables for the CommandInterpreter, which contain the help string
[Lldb-commits] [lldb] r280902 - Force the initialization of the m_type ivar in
Author: jmolenda
Date: Wed Sep 7 21:26:58 2016
New Revision: 280902
URL: http://llvm.org/viewvc/llvm-project?rev=280902&view=rev
Log:
Force the initialization of the m_type ivar in
Function::GetStartLineSourceInfo before we try to
return the start line information about a function;
this function requires it to have been initialized.
Modified:
lldb/trunk/source/Symbol/Function.cpp
Modified: lldb/trunk/source/Symbol/Function.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/Function.cpp?rev=280902&r1=280901&r2=280902&view=diff
==
--- lldb/trunk/source/Symbol/Function.cpp (original)
+++ lldb/trunk/source/Symbol/Function.cpp Wed Sep 7 21:26:58 2016
@@ -163,6 +163,9 @@ void Function::GetStartLineSourceInfo(Fi
if (m_comp_unit == nullptr)
return;
+ // Initialize m_type if it hasn't been initialized already
+ GetType();
+
if (m_type != nullptr && m_type->GetDeclaration().GetLine() != 0) {
source_file = m_type->GetDeclaration().GetFile();
line_no = m_type->GetDeclaration().GetLine();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r280903 - I had a problem with one SDK where dispatch_release was actually a
Author: jmolenda
Date: Wed Sep 7 21:29:40 2016
New Revision: 280903
URL: http://llvm.org/viewvc/llvm-project?rev=280903&view=rev
Log:
I had a problem with one SDK where dispatch_release was actually a
macro, so writing ::dispatch_release did not work as expected.
Remove the global anon namespace :: designation; the header will
get us the correct declaration.
Modified:
lldb/trunk/source/Host/macosx/Host.mm
Modified: lldb/trunk/source/Host/macosx/Host.mm
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/macosx/Host.mm?rev=280903&r1=280902&r2=280903&view=diff
==
--- lldb/trunk/source/Host/macosx/Host.mm (original)
+++ lldb/trunk/source/Host/macosx/Host.mm Wed Sep 7 21:29:40 2016
@@ -1410,7 +1410,7 @@ HostThread Host::StartMonitoringChildPro
if (source) {
Host::MonitorChildProcessCallback callback_copy = callback;
::dispatch_source_set_cancel_handler(source, ^{
- ::dispatch_release(source);
+ dispatch_release(source);
});
::dispatch_source_set_event_handler(source, ^{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r280906 - I'm experimenting with changing how the mixed source & assembly
Author: jmolenda
Date: Thu Sep 8 00:12:41 2016
New Revision: 280906
URL: http://llvm.org/viewvc/llvm-project?rev=280906&view=rev
Log:
I'm experimenting with changing how the mixed source & assembly
mode in lldb works. I've been discussing this with Jim Ingham,
Greg Clayton, and Kate Stone for the past week or two.
Previously lldb would print three source lines (centered on the
line table entry line for the current line) followed by the assembly.
It would print the context information (module`function + offset)
before those three lines of source.
Now lldb will print up to two lines before/after the line table
entry. It prints two '*' characters for the line table line to
make it clear what line is showing assembly. There is one line of
whitespace before/after the source lines so the separation between
source & assembly is clearer. I don't print the context line
(module`function + offset). I stop printing context lines if it's
a different line table entry, or if it's a source line I've already
printed as context to another source line. If I have two line table
entries one after another for the same source line (I get these often
with clang - with different column information in them), I only print
the source line once.
I'm also using the target.process.thread.step-avoid-regexp setting
(which keeps you from stepping into STL functions that have been inlined
into your own code) and avoid printing any source lines from functions
that match that regexp.
When lldb disassembles into a new function, it will try to find the
declaration line # for the function and print all of the source lines
between the decl and the first line table entry (usually a { curly brace)
so we have a good chance of including the arguments, at least with the
debug info emitted by clang.
Finally, the # of source lines of context to show has been separated
from whether we're doing mixed source & assembly or not. Previously
specifying 0 lines of context would turn off mixed source & assembly.
I think there's room for improvement, and maybe some bugs I haven't
found yet, but it's in good enough shape to upstream and iterate at
this point.
I'm not sure how best to indicate which source line is the actual line
table # versus context lines. I'm using '**' right now. Both Kate
and Greg had the initial idea to reuse '->' (normally used to indicate
"currently executing source line") - I tried it but I wasn't thrilled,
I'm too used to the established meaning of ->.
Greg had the interesting idea of avoiding context source lines only
in two line table entries in the same source file. So we'd print
two lines before & after a source line, and then the next line table
entry (if it was on the next source line after those two context lines)
we'd display only the following two lines -- the previous two had just
been printed. If an inline source line was printed between these two,
though, we'd print the context lines for both of them. It's an
interesting idea, and I want to see how it works with both -O0 and -O3
codegen where we have different amounts of inlining.
Modified:
lldb/trunk/include/lldb/Core/Disassembler.h
lldb/trunk/source/Commands/CommandObjectDisassemble.cpp
lldb/trunk/source/Core/Disassembler.cpp
lldb/trunk/source/Target/StackFrame.cpp
Modified: lldb/trunk/include/lldb/Core/Disassembler.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Disassembler.h?rev=280906&r1=280905&r2=280906&view=diff
==
--- lldb/trunk/include/lldb/Core/Disassembler.h (original)
+++ lldb/trunk/include/lldb/Core/Disassembler.h Thu Sep 8 00:12:41 2016
@@ -22,7 +22,9 @@
#include "lldb/Core/EmulateInstruction.h"
#include "lldb/Core/Opcode.h"
#include "lldb/Core/PluginInterface.h"
+#include "lldb/Host/FileSpec.h"
#include "lldb/Interpreter/OptionValue.h"
+#include "lldb/Symbol/LineEntry.h"
#include "lldb/lldb-private.h"
namespace lldb_private {
@@ -314,6 +316,7 @@ public:
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx,
const AddressRange &range, uint32_t num_instructions,
+ bool mixed_source_and_assembly,
uint32_t num_mixed_context_lines, uint32_t options,
Stream &strm);
@@ -321,6 +324,7 @@ public:
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx, const Address
&start,
uint32_t num_instructions,
+ bool mixed_source_and_assembly,
uint32_t num_mixed_context_lines, uint32_t options,
Stream &strm);
@@ -328,22 +332,21 @@ public:
Disassemble(Debugger &debugger, const ArchSpec &arch, const char
*plugin_name,
const char *flavor, const Execu
[Lldb-commits] [PATCH] D24331: Fix about a dozen compile warnings
ki.stfu created this revision.
ki.stfu added reviewers: clayborg, jingham, zturner.
ki.stfu added a subscriber: lldb-commits.
It fixes the following compile warnings:
1. '0' flag ignored with precision and ‘%d’ gnu_printf format
2. enumeral and non-enumeral type in conditional expression
3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ...
4. enumeration value ‘...’ not handled in switch
5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’
casts away qualifiers
6. extra ‘;’
7. comparison between signed and unsigned integer expressions
8. variable ‘register_operand’ set but not used
9. control reaches end of non-void function
https://reviews.llvm.org/D24331
Files:
source/Core/Log.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
source/Plugins/Process/elf-core/ProcessElfCore.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/minidump/MinidumpParser.cpp
source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
source/Target/StackFrame.cpp
Index: source/Target/StackFrame.cpp
===
--- source/Target/StackFrame.cpp
+++ source/Target/StackFrame.cpp
@@ -1279,6 +1279,9 @@
return std::make_pair(nullptr, 0);
}
}
+ default:
+// Make compiler happy with adding default case
+return std::make_pair(nullptr, 0);
}
}
@@ -1292,7 +1295,7 @@
}
return std::make_pair(nullptr, 0);
}
-};
+}
lldb::ValueObjectSP StackFrame::GuessValueForAddress(lldb::addr_t addr) {
TargetSP target_sp = CalculateTarget();
@@ -1421,7 +1424,7 @@
Error error;
ValueObjectSP pointee = base->Dereference(error);
- if (offset >= pointee->GetByteSize()) {
+ if (offset > 0 && uint64_t(offset) >= pointee->GetByteSize()) {
int64_t index = offset / pointee->GetByteSize();
offset = offset % pointee->GetByteSize();
const bool can_create = true;
@@ -1602,6 +1605,9 @@
continue;
}
+// Ignore an unused-variable warning for a register operand.
+(void)register_operand;
+
// We have an origin operand. Can we track its value down?
switch (origin_operand->m_type) {
default:
Index: source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
===
--- source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+++ source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
@@ -518,7 +518,7 @@
// 0x. If we use the unsigned long long
// it will work as expected.
const uint64_t uval = PyLong_AsUnsignedLongLong(m_py_obj);
- result = *((int64_t *)&uval);
+ result = *((const int64_t *)&uval);
}
return result;
}
Index: source/Plugins/Process/minidump/MinidumpParser.cpp
===
--- source/Plugins/Process/minidump/MinidumpParser.cpp
+++ source/Plugins/Process/minidump/MinidumpParser.cpp
@@ -138,6 +138,8 @@
case MinidumpCPUArchitecture::ARM64:
arch_spec.GetTriple().setArch(llvm::Triple::ArchType::aarch64);
break;
+ default:
+break;
}
return arch_spec;
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -3567,7 +3567,7 @@
error.SetErrorStringWithFormat("configuring StructuredData feature %s "
"failed when sending packet: "
"PacketResult=%d",
- type_name.AsCString(), result);
+ type_name.AsCString(), (int)result);
}
return error;
}
Index: source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -139,9 +139,9 @@
// Keep a separate map of permissions that that isn't coalesced so all ranges
// are maintained.
const uint32_t permissions =
- ((header->p_flags & llvm::ELF::PF_R) ? lldb::ePermissionsReadable : 0) |
- ((header->p_flags & llvm::ELF::PF_W) ? lldb::ePermissionsWritable : 0) |
- ((header->p_flags & llvm::ELF::PF_X) ? lldb::ePermissionsExecutable : 0);
+ ((header->p_flags & llvm::ELF::PF_R) ? lldb::ePermissionsReadable : 0u) |
+ ((header->p_flags & llvm::ELF::PF_W) ? lldb::ePermissionsWritable : 0u) |
+ ((header->p_flags & llvm::ELF::PF_X) ? lldb::ePermissionsExecutable : 0u);
m_core_range_infos.Append(
VMRangeToPermissions::Entry(addr, header->p_memsz, permissions));
Index: source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
Re: [Lldb-commits] [PATCH] D24331: Fix about a dozen compile warnings
ki.stfu added a comment.
BTW, the following warnings remain:
1. unrecognized command line option ‘-Wno-vla-extension’
2. unrecognized command line option ‘-Wno-deprecated-register’
3. comparison of unsigned expression >= 0 is always true
[2782/3295] Building CXX object
tools/lldb/source/Plugins/Instruction/ARM/CMakeFiles/lldbPluginInstructionARM.dir/EmulationStateARM.cpp.o
../tools/lldb/source/Plugins/Instruction/ARM/EmulationStateARM.cpp: In member
function ‘bool EmulationStateARM::StorePseudoRegisterValue(uint32_t, uint64_t)’:
../tools/lldb/source/Plugins/Instruction/ARM/EmulationStateARM.cpp:69:17:
warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
if ((dwarf_r0 <= reg_num) && (reg_num <= dwarf_cpsr))
^
../tools/lldb/source/Plugins/Instruction/ARM/EmulationStateARM.cpp: In member
function ‘uint64_t EmulationStateARM::ReadPseudoRegisterValue(uint32_t, bool&)’:
../tools/lldb/source/Plugins/Instruction/ARM/EmulationStateARM.cpp:92:17:
warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
if ((dwarf_r0 <= reg_num) && (reg_num <= dwarf_cpsr))
^
...
[3136/3295] Building CXX object
tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/ARM64_DWARF_Registers.cpp.o
../tools/lldb/source/Utility/ARM64_DWARF_Registers.cpp: In function ‘bool
arm64_dwarf::GetRegisterInfo(unsigned int, lldb_private::RegisterInfo&)’:
../tools/lldb/source/Utility/ARM64_DWARF_Registers.cpp:175:15: warning:
comparison of unsigned expression >= 0 is always true [-Wtype-limits]
if (reg_num >= x0 && reg_num <= pc) {
^
4. format not a string literal and no format arguments
[3217/3295] Building CXX object
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
tools/lldb/scripts/LLDBWrapPython.cpp: In function ‘PyObject*
_wrap_SBError_SetErrorStringWithFormat__SWIG_3(PyObject*, PyObject*)’:
tools/lldb/scripts/LLDBWrapPython.cpp:28426:70: warning: format not a string
literal and no format arguments [-Wformat-security]
result = (int)(arg1)->SetErrorStringWithFormat((char const *)arg2);
^
5. comparison between signed and unsigned integer expressions
tools/lldb/scripts/LLDBWrapPython.cpp: In function ‘PyObject*
_wrap_SBTarget_BreakpointCreateByNames__SWIG_0(PyObject*, PyObject*)’:
tools/lldb/scripts/LLDBWrapPython.cpp:55744:21: warning: comparison between
signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < arg3; i++) {
^
tools/lldb/scripts/LLDBWrapPython.cpp: In function ‘PyObject*
_wrap_SBTarget_BreakpointCreateByNames__SWIG_1(PyObject*, PyObject*)’:
tools/lldb/scripts/LLDBWrapPython.cpp:55836:21: warning: comparison between
signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < arg3; i++) {
^
tools/lldb/scripts/LLDBWrapPython.cpp: In function ‘PyObject*
_wrap_SBTarget_BreakpointCreateByNames__SWIG_2(PyObject*, PyObject*)’:
tools/lldb/scripts/LLDBWrapPython.cpp:55937:21: warning: comparison between
signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < arg3; i++) {
^
https://reviews.llvm.org/D24331
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
