[Lldb-commits] [PATCH] D38394: Fix dumping of characters with non-standard sizes
petpav01 added inline comments.
Comment at: source/Utility/DataExtractor.cpp:566
size_t byte_size) const {
- switch (byte_size) {
- case 1:
-return GetU8(offset_ptr);
-break;
- case 2:
-return GetU16(offset_ptr);
-break;
- case 4:
-return GetU32(offset_ptr);
-break;
- default:
-assert(false && "GetMaxU32 unhandled case!");
-break;
- }
- return 0;
+ assert(byte_size <= 4 && "GetMaxU32 unhandled case!");
+ return GetMaxU64(offset_ptr, byte_size);
zturner wrote:
> jingham wrote:
> > petpav01 wrote:
> > > jingham wrote:
> > > > This is trivial, and you didn't change what was there, but this message
> > > > makes it sound like this is just something we haven't gotten to yet.
> > > > It's really "You passed in an illegal byte size"... Might be clearer
> > > > if the message said that.
> > > I was not sure what is the expected behaviour when the input `byte_size`
> > > exceeds the size of the return type of each of these `GetMax...()`
> > > methods. The current behaviour is to assert this situation but comments
> > > describing the methods (in both `DataExtractor.cpp` and
> > > `DataExtractor.h`) say that nothing should get extracted in these cases
> > > and zero is returned.
> > >
> > > Maybe the patch should go a bit further and clean this up as follows:
> > > * Remove duplicated comments in `DataExtractor.cpp` for
> > > `DataExtractor::GetMaxU32()` and `GetMaxU64()` and keep only their
> > > Doxygen versions in `DataExtractor.h`.
> > > * Update comments in `DataExtractor.h` for `DataExtractor::GetMaxU32()`,
> > > `GetMaxU64()`, `GetMaxS64()`, `GetMaxU64Bitfield()` and
> > > `GetMaxS64Bitfield()` to match the current implementation.
> > > * Change assertion text in `DataExtractor::GetMaxU32()` and `GetMaxU64()`
> > > from "unhandled case" to "invalid byte size".
> > >
> > > Does this sound reasonable?
> > The released versions of lldb - at least the ones Apple releases - have
> > asserts disabled. This isn't unique to lldb, clang does the same thing.
> >
> > I do my day-to-day debugging using a TOT build with asserts enabled, and we
> > run the testsuite that way so the asserts catch errors at this stage. But
> > for the general public, the function will behave as described. It would be
> > great to remove the duplicated docs - that's just begging for one or the
> > other to get out of date. But the descriptions are functionally correct.
> > And then changing the text to "invalid byte size" also seems good to me.
> Being pedantic, this *is* a functionality change. Previously, we would
> assert on a size of 3 or 0, with this change we will allow those cases
> through.
To explain myself better, what I was thinking about is that e.g. `GetMaxU64()`
should have part:
"\a byte_size should have a value greater than or equal to one and less than or
equal to eight since the return value is 64 bits wide. Any \a byte_size values
less than 1 or greater than 8 will result in nothing being extracted, and zero
being returned."
changed to:
"\a byte_size must have a value greater than or equal to one and less than or
equal to eight since the return value is 64 bits wide. The behaviour is
undefined for any \a byte_size values less than 1 or greater than 8."
This way the comment provides information that does not depend on whether
assertions are enabled or not. The behaviour for `byte_size > 8` is said to be
undefined in the updated description because it either results in an assertion
failure or some undefined behaviour if asserts are disabled.
If the behaviour for `byte_size > 4/8` with assertions disabled should actually
be that these methods still return 0 and do not advance the offset then the
patch has two bugs:
* The general case added in `GetMaxU64()` is not correct. It returns an
unexpected value for `byte_size > 8` and advances the offset.
* `GetMaxU32()` needs to have `if (byte_size > 4) return 0;` added before it
calls `GetMaxU64()` to avoid the same problem for any `byte_size > 4`.
An additional thing is that the patch causes that `byte_size == 0` is now fully
valid and does not assert. This might not be the best idea given that the
current descriptions say that `byte_size` values should be in interval [1,
4/8]. I will add the assertion for `byte_size == 0` back in the updated patch
so the changes affect/enable only `byte_size` in range [1, 4/8] (which are
clear to be valid) and the zero corner case has its behaviour unchanged.
https://reviews.llvm.org/D38394
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
lemo created this revision.
Herald added a subscriber: mgorny.
Neither LLDB_CONFIGURATION_DEBUG nor LLDB_CONFIGURATION_RELEASE were ever set
in the CMake LLDB project.
Also cleaned up a questionable #ifdef in SharingPtr.h, removing all the
references to LLDB_CONFIGURATION_BUILD_AND_INTEGRATION in the process.
https://reviews.llvm.org/D38552
Files:
CMakeLists.txt
include/lldb/Utility/SharingPtr.h
Index: include/lldb/Utility/SharingPtr.h
===
--- include/lldb/Utility/SharingPtr.h
+++ include/lldb/Utility/SharingPtr.h
@@ -529,16 +529,7 @@
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -11,6 +11,13 @@
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
Index: include/lldb/Utility/SharingPtr.h
===
--- include/lldb/Utility/SharingPtr.h
+++ include/lldb/Utility/SharingPtr.h
@@ -529,16 +529,7 @@
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -11,6 +11,13 @@
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
zturner added inline comments. Comment at: CMakeLists.txt:15 +# Define the LLDB_CONFIGURATION_xxx matching the build type +if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) + add_definitions( -DLLDB_CONFIGURATION_DEBUG ) I'm pretty sure that if you run CMake without specifying anything for `CMAKE_BUILD_TYPE` then the default is debug, but it doesn't internally set `CMAKE_BUILD_TYPE=Debug`. Can you double check this handles the default case appropriately? https://reviews.llvm.org/D38552 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
lemo added a comment. Good point, I wouldn't be surprised if that was the case at some point, but right now the main llvm CMakeLists.txt has this: ... if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES) message(STATUS "No build type selected, default to Debug") set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Build type (default Debug)" FORCE) endif() ... I will double check though, thanks for pointing this out. https://reviews.llvm.org/D38552 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
lemo updated this revision to Diff 117704.
lemo added a comment.
Changed how CMAKE_BUILD_TYPE is tested to ensure we default to
LLDB_CONFIGURATION_DEBUG.
https://reviews.llvm.org/D38552
Files:
CMakeLists.txt
include/lldb/Utility/SharingPtr.h
Index: include/lldb/Utility/SharingPtr.h
===
--- include/lldb/Utility/SharingPtr.h
+++ include/lldb/Utility/SharingPtr.h
@@ -529,16 +529,7 @@
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -11,6 +11,13 @@
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
Index: include/lldb/Utility/SharingPtr.h
===
--- include/lldb/Utility/SharingPtr.h
+++ include/lldb/Utility/SharingPtr.h
@@ -529,16 +529,7 @@
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -11,6 +11,13 @@
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
zturner added inline comments. Comment at: CMakeLists.txt:15 +# Define the LLDB_CONFIGURATION_xxx matching the build type +if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) + add_definitions( -DLLDB_CONFIGURATION_RELEASE ) Isn't this identical to the code before? https://reviews.llvm.org/D38552 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
Identical, no - note the checks are inverted. Definitely uglier, but it's defaulting to LLDB_CONFIGURATION_DEBUG if CMAKE_BUILD_TYPE is not defined, right? With the current defaulting rule I pointed out both versions should be equivalent. If anything I prefer the 1st version since I like to avoid negations in conditional expressions, but it's a minor thing and I'll leave the final choice up to you. On Wed, Oct 4, 2017 at 11:22 AM, Zachary Turner via Phabricator < revi...@reviews.llvm.org> wrote: > zturner added inline comments. > > > > Comment at: CMakeLists.txt:15 > +# Define the LLDB_CONFIGURATION_xxx matching the build type > +if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) > + add_definitions( -DLLDB_CONFIGURATION_RELEASE ) > > Isn't this identical to the code before? > > > https://reviews.llvm.org/D38552 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38552: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
This revision was automatically updated to reflect the committed changes.
Closed by commit rL314929: LLDB cmake fix: define LLDB_CONFIGURATION_xxx based
on the build type (authored by lemo).
Changed prior to commit:
https://reviews.llvm.org/D38552?vs=117704&id=117730#toc
Repository:
rL LLVM
https://reviews.llvm.org/D38552
Files:
lldb/trunk/CMakeLists.txt
lldb/trunk/include/lldb/Utility/SharingPtr.h
Index: lldb/trunk/include/lldb/Utility/SharingPtr.h
===
--- lldb/trunk/include/lldb/Utility/SharingPtr.h
+++ lldb/trunk/include/lldb/Utility/SharingPtr.h
@@ -529,16 +529,7 @@
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
Index: lldb/trunk/CMakeLists.txt
===
--- lldb/trunk/CMakeLists.txt
+++ lldb/trunk/CMakeLists.txt
@@ -11,6 +11,13 @@
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
Index: lldb/trunk/include/lldb/Utility/SharingPtr.h
===
--- lldb/trunk/include/lldb/Utility/SharingPtr.h
+++ lldb/trunk/include/lldb/Utility/SharingPtr.h
@@ -529,16 +529,7 @@
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
Index: lldb/trunk/CMakeLists.txt
===
--- lldb/trunk/CMakeLists.txt
+++ lldb/trunk/CMakeLists.txt
@@ -11,6 +11,13 @@
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r314929 - LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
Author: lemo
Date: Wed Oct 4 13:23:56 2017
New Revision: 314929
URL: http://llvm.org/viewvc/llvm-project?rev=314929&view=rev
Log:
LLDB cmake fix: define LLDB_CONFIGURATION_xxx based on the build type
Neither LLDB_CONFIGURATION_DEBUG nor LLDB_CONFIGURATION_RELEASE were ever set
in the CMake LLDB project.
Also cleaned up a questionable #ifdef in SharingPtr.h, removing all the
references to LLDB_CONFIGURATION_BUILD_AND_INTEGRATION in the process.
Differential Revision: https://reviews.llvm.org/D38552
Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/include/lldb/Utility/SharingPtr.h
Modified: lldb/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=314929&r1=314928&r2=314929&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Wed Oct 4 13:23:56 2017
@@ -11,6 +11,13 @@ include(LLDBStandalone)
include(LLDBConfig)
include(AddLLDB)
+# Define the LLDB_CONFIGURATION_xxx matching the build type
+if( uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+ add_definitions( -DLLDB_CONFIGURATION_DEBUG )
+else()
+ add_definitions( -DLLDB_CONFIGURATION_RELEASE )
+endif()
+
if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
else()
Modified: lldb/trunk/include/lldb/Utility/SharingPtr.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/SharingPtr.h?rev=314929&r1=314928&r2=314929&view=diff
==
--- lldb/trunk/include/lldb/Utility/SharingPtr.h (original)
+++ lldb/trunk/include/lldb/Utility/SharingPtr.h Wed Oct 4 13:23:56 2017
@@ -529,16 +529,7 @@ public:
~IntrusiveSharingPtr() {
release_shared();
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
-// NULL out the pointer in objects which can help with leaks detection.
-// We don't enable this for LLDB_CONFIGURATION_BUILD_AND_INTEGRATION or
-// when none of the LLDB_CONFIGURATION_XXX macros are defined since
-// those would be builds for release. But for debug and release builds
-// that are for development, we NULL out the pointers to catch potential
-// issues.
ptr_ = nullptr;
-#endif // #if defined (LLDB_CONFIGURATION_DEBUG) || defined
- // (LLDB_CONFIGURATION_RELEASE)
}
T &operator*() const { return *ptr_; }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D38568: [lldb] Enable using out-of-tree dwps
alexshap created this revision.
Herald added subscribers: JDevlieghere, aprantl.
Previously LLDB required dwp to be located next to the executable file
(see the code in SymbolFileDWARF::GetDwpSymbolFile).
This diff uses the helper function Symbols::LocateExecutableSymbolFile
to search for DWP files in the standard locations for debug symbols.
Test plan:
Build a toy test example
main.cpp
clang -gsplit-dwarf -g -O0 main.cpp -o main.exe
llvm-dwp -e main.exe -o main.exe.dwp
mkdir -p debug_symbols
mv main.exe.dwp debug_symbols/main.exe.dwp
rm -f main.dwo
Run lldb:
lldb
settings set target.debug-file-search-paths ./debug_symbols
file ./main.exe
br set --name f
r
Check that debugging works
(setting breakpoints, printing local variables (this was not working before))
Repository:
rL LLVM
https://reviews.llvm.org/D38568
Files:
source/Host/common/Symbols.cpp
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -30,6 +30,7 @@
#include "lldb/Host/FileSystem.h"
#include "lldb/Host/Host.h"
+#include "lldb/Host/Symbols.h"
#include "lldb/Interpreter/OptionValueFileSpecList.h"
#include "lldb/Interpreter/OptionValueProperties.h"
@@ -4352,7 +4353,11 @@
SymbolFileDWARFDwp *SymbolFileDWARF::GetDwpSymbolFile() {
llvm::call_once(m_dwp_symfile_once_flag, [this]() {
-FileSpec dwp_filespec(m_obj_file->GetFileSpec().GetPath() + ".dwp", false);
+ModuleSpec module_spec;
+module_spec.GetFileSpec() = m_obj_file->GetFileSpec();
+module_spec.GetSymbolFileSpec() =
+FileSpec(m_obj_file->GetFileSpec().GetPath() + ".dwp", false);
+FileSpec dwp_filespec = Symbols::LocateExecutableSymbolFile(module_spec);
if (dwp_filespec.Exists()) {
m_dwp_symfile = SymbolFileDWARFDwp::Create(GetObjectFile()->GetModule(),
dwp_filespec);
Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -285,7 +285,13 @@
if (num_specs == 1) {
ModuleSpec mspec;
if (specs.GetModuleSpecAtIndex(0, mspec)) {
- if (mspec.GetUUID() == module_uuid)
+ // FIXME: at the moment llvm-dwp doesn't output build ids,
+ // nor does binutils dwp. Thus in the case of DWPs
+ // we skip uuids check. This needs to be fixed
+ // to avoid consistency issues as soon as
+ // llvm-dwp and binutils dwp gain support for build ids.
+ if (file_spec.GetFileNameExtension().GetStringRef() == "dwp" ||
+ mspec.GetUUID() == module_uuid)
return file_spec;
}
}
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -30,6 +30,7 @@
#include "lldb/Host/FileSystem.h"
#include "lldb/Host/Host.h"
+#include "lldb/Host/Symbols.h"
#include "lldb/Interpreter/OptionValueFileSpecList.h"
#include "lldb/Interpreter/OptionValueProperties.h"
@@ -4352,7 +4353,11 @@
SymbolFileDWARFDwp *SymbolFileDWARF::GetDwpSymbolFile() {
llvm::call_once(m_dwp_symfile_once_flag, [this]() {
-FileSpec dwp_filespec(m_obj_file->GetFileSpec().GetPath() + ".dwp", false);
+ModuleSpec module_spec;
+module_spec.GetFileSpec() = m_obj_file->GetFileSpec();
+module_spec.GetSymbolFileSpec() =
+FileSpec(m_obj_file->GetFileSpec().GetPath() + ".dwp", false);
+FileSpec dwp_filespec = Symbols::LocateExecutableSymbolFile(module_spec);
if (dwp_filespec.Exists()) {
m_dwp_symfile = SymbolFileDWARFDwp::Create(GetObjectFile()->GetModule(),
dwp_filespec);
Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -285,7 +285,13 @@
if (num_specs == 1) {
ModuleSpec mspec;
if (specs.GetModuleSpecAtIndex(0, mspec)) {
- if (mspec.GetUUID() == module_uuid)
+ // FIXME: at the moment llvm-dwp doesn't output build ids,
+ // nor does binutils dwp. Thus in the case of DWPs
+ // we skip uuids check. This needs to be fixed
+ // to avoid consistency issues as soon as
+ // llvm-dwp and binutils dwp gain support for build ids.
+ if (file_spec.GetFileNameExtension().GetStringRef() == "dwp" ||
+ mspec.GetUUID() == module_uuid)
return file_spec;
}
[Lldb-commits] [lldb] r314958 - Another silly little thing you can do with Python commands.
Author: jingham
Date: Wed Oct 4 17:49:49 2017
New Revision: 314958
URL: http://llvm.org/viewvc/llvm-project?rev=314958&view=rev
Log:
Another silly little thing you can do with Python commands.
Sometimes you want to step along and print a local each time as you go.
You can do that with stop hooks, but that's a little heavy-weight. This
is a sketch of a command that steps and then does "frame variable" on all
its arguments.
Added:
lldb/trunk/examples/python/step_and_print.py
Added: lldb/trunk/examples/python/step_and_print.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/python/step_and_print.py?rev=314958&view=auto
==
--- lldb/trunk/examples/python/step_and_print.py (added)
+++ lldb/trunk/examples/python/step_and_print.py Wed Oct 4 17:49:49 2017
@@ -0,0 +1,24 @@
+""" Does a step-over then prints the local variables or only the ones passed
in """
+import lldb
+
+class StepAndPrint:
+def __init__(self, debugger, unused):
+return
+
+def __call__(self, debugger, command, exe_ctx, result):
+# Set the command to synchronous so the step will complete
+# before we try to run the frame variable.
+old_async = debugger.GetAsync()
+debugger.SetAsync(False)
+
+debugger.HandleCommand("thread step-over")
+print("-- Values: ---\n")
+debugger.HandleCommand("frame variable %s"%(command))
+
+debugger.SetAsync(old_async)
+
+def get_short_help(self):
+return "Does a step-over then runs frame variable passing the command
args to it\n"
+
+def __lldb_init_module(debugger, unused):
+debugger.HandleCommand("command script add -c step_and_print.StepAndPrint
sap")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r314959 - Work around a bug in the C++ expression parser.
Author: jingham
Date: Wed Oct 4 18:00:29 2017
New Revision: 314959
URL: http://llvm.org/viewvc/llvm-project?rev=314959&view=rev
Log:
Work around a bug in the C++ expression parser.
When the expression parser does name resolution for local
variables in C++ closures it doesn't give the local name
priority over other global symbols of the same name. heap.py
uses "info" which is a fairly common name, and so the commands
in it fail. This is a workaround, just use lldb_info not info.
Modified:
lldb/trunk/examples/darwin/heap_find/heap.py
Modified: lldb/trunk/examples/darwin/heap_find/heap.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/darwin/heap_find/heap.py?rev=314959&r1=314958&r2=314959&view=diff
==
--- lldb/trunk/examples/darwin/heap_find/heap.py (original)
+++ lldb/trunk/examples/darwin/heap_find/heap.py Wed Oct 4 18:00:29 2017
@@ -576,19 +576,19 @@ typedef struct $malloc_stack_history {
unsigned idx;
malloc_stack_entry entries[MAX_HISTORY];
} $malloc_stack_history;
-$malloc_stack_history info = { (task_t)mach_task_self(), 0 };
+$malloc_stack_history lldb_info = { (task_t)mach_task_self(), 0 };
uint32_t max_stack_frames = MAX_FRAMES;
enumerate_callback_t callback = [] (mach_stack_logging_record_t stack_record,
void *baton) -> void {
-$malloc_stack_history *info = ($malloc_stack_history *)baton;
-if (info->idx < MAX_HISTORY) {
-malloc_stack_entry *stack_entry = &(info->entries[info->idx]);
+$malloc_stack_history *lldb_info = ($malloc_stack_history *)baton;
+if (lldb_info->idx < MAX_HISTORY) {
+malloc_stack_entry *stack_entry =
&(lldb_info->entries[lldb_info->idx]);
stack_entry->address = stack_record.address;
stack_entry->type_flags = stack_record.type_flags;
stack_entry->argument = stack_record.argument;
stack_entry->num_frames = 0;
stack_entry->frames[0] = 0;
stack_entry->frames_err =
(kern_return_t)__mach_stack_logging_frames_for_uniqued_stack (
-info->task,
+lldb_info->task,
stack_record.stack_identifier,
stack_entry->frames,
(uint32_t)MAX_FRAMES,
@@ -597,10 +597,10 @@ enumerate_callback_t callback = [] (mach
if (stack_entry->num_frames < MAX_FRAMES)
stack_entry->frames[stack_entry->num_frames] = 0;
}
-++info->idx;
+++lldb_info->idx;
};
-(kern_return_t)__mach_stack_logging_enumerate_records (info.task,
(uint64_t)0x%x, callback, &info);
-info''' % (options.max_frames, options.max_history, addr)
+(kern_return_t)__mach_stack_logging_enumerate_records (lldb_info.task,
(uint64_t)0x%x, callback, &lldb_info);
+lldb_info''' % (options.max_frames, options.max_history, addr)
frame = lldb.debugger.GetSelectedTarget().GetProcess(
).GetSelectedThread().GetSelectedFrame()
@@ -924,18 +924,18 @@ typedef struct callback_baton_t {
void *ptr;
} callback_baton_t;
range_callback_t range_callback = [](task_t task, void *baton, unsigned type,
uintptr_t ptr_addr, uintptr_t ptr_size) -> void {
-callback_baton_t *info = (callback_baton_t *)baton;
+callback_baton_t *lldb_info = (callback_baton_t *)baton;
typedef void* T;
const unsigned size = sizeof(T);
T *array = (T*)ptr_addr;
for (unsigned idx = 0; ((idx + 1) * sizeof(T)) <= ptr_size; ++idx) {
-if (array[idx] == info->ptr) {
-if (info->num_matches < MAX_MATCHES) {
-info->matches[info->num_matches].addr = (void*)ptr_addr;
-info->matches[info->num_matches].size = ptr_size;
-info->matches[info->num_matches].offset = idx*sizeof(T);
-info->matches[info->num_matches].type = type;
-++info->num_matches;
+if (array[idx] == lldb_info->ptr) {
+if (lldb_info->num_matches < MAX_MATCHES) {
+lldb_info->matches[lldb_info->num_matches].addr =
(void*)ptr_addr;
+lldb_info->matches[lldb_info->num_matches].size = ptr_size;
+lldb_info->matches[lldb_info->num_matches].offset =
idx*sizeof(T);
+lldb_info->matches[lldb_info->num_matches].type = type;
+++lldb_info->num_matches;
}
}
}
@@ -1033,18 +1033,18 @@ typedef struct callback_baton_t {
unsigned cstr_len;
} callback_baton_t;
range_callback_t range_callback = [](task_t task, void *baton, unsigned type,
uintptr_t ptr_addr, uintptr_t ptr_size) -> void {
-callback_baton_t *info = (callback_baton_t *)baton;
-if (info->cstr_len < ptr_size) {
+callback_baton_t *lldb_info = (callback_baton_t *)baton;
+if (lldb_info->cstr_len < ptr_size) {
const char *begin = (const char *)ptr_addr;
const char *end = begin + ptr_size - info->cstr_len;
for (const char *s = begin; s < end; ++s) {
-if ((int)memcmp(s, info->cstr, info->cstr_l
