[Lldb-commits] [lldb] r317327 - Add type to FileSpec::PathSyntax enum.
Author: dhinton
Date: Fri Nov 3 07:59:36 2017
New Revision: 317327
URL: http://llvm.org/viewvc/llvm-project?rev=317327&view=rev
Log:
Add type to FileSpec::PathSyntax enum.
Summary:
Add type to FileSpec::PathSyntax enum to decrease size for
FileSpec on systems with 32 bit pointers.
Thanks to @zturner for pointing this out.
Differential Revision: https://reviews.llvm.org/D39574
Modified:
lldb/trunk/include/lldb/Utility/FileSpec.h
Modified: lldb/trunk/include/lldb/Utility/FileSpec.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/FileSpec.h?rev=317327&r1=317326&r2=317327&view=diff
==
--- lldb/trunk/include/lldb/Utility/FileSpec.h (original)
+++ lldb/trunk/include/lldb/Utility/FileSpec.h Fri Nov 3 07:59:36 2017
@@ -61,7 +61,7 @@ namespace lldb_private {
//--
class FileSpec {
public:
- enum PathSyntax {
+ enum PathSyntax : unsigned char {
ePathSyntaxPosix,
ePathSyntaxWindows,
ePathSyntaxHostNative
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r318164 - Add check for self-assignment. NFC
Author: dhinton
Date: Tue Nov 14 10:19:41 2017
New Revision: 318164
URL: http://llvm.org/viewvc/llvm-project?rev=318164&view=rev
Log:
Add check for self-assignment. NFC
Differential Revision: https://reviews.llvm.org/D39578
Modified:
lldb/trunk/source/Core/RegisterValue.cpp
lldb/trunk/source/Core/Value.cpp
Modified: lldb/trunk/source/Core/RegisterValue.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/RegisterValue.cpp?rev=318164&r1=318163&r2=318164&view=diff
==
--- lldb/trunk/source/Core/RegisterValue.cpp (original)
+++ lldb/trunk/source/Core/RegisterValue.cpp Tue Nov 14 10:19:41 2017
@@ -539,6 +539,9 @@ bool RegisterValue::SignExtend(uint32_t
}
bool RegisterValue::CopyValue(const RegisterValue &rhs) {
+ if (this == &rhs)
+return rhs.m_type == eTypeInvalid ? false : true;
+
m_type = rhs.m_type;
switch (m_type) {
case eTypeInvalid:
Modified: lldb/trunk/source/Core/Value.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Value.cpp?rev=318164&r1=318163&r2=318164&view=diff
==
--- lldb/trunk/source/Core/Value.cpp (original)
+++ lldb/trunk/source/Core/Value.cpp Tue Nov 14 10:19:41 2017
@@ -142,6 +142,9 @@ Type *Value::GetType() {
}
size_t Value::AppendDataToHostBuffer(const Value &rhs) {
+ if (this == &rhs)
+return 0;
+
size_t curr_size = m_data_buffer.GetByteSize();
Status error;
switch (rhs.GetValueType()) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r325442 - [cmake] Fix LLDB_CODESIGN_IDENTITY logic.
Author: dhinton
Date: Sat Feb 17 11:17:21 2018
New Revision: 325442
URL: http://llvm.org/viewvc/llvm-project?rev=325442&view=rev
Log:
[cmake] Fix LLDB_CODESIGN_IDENTITY logic.
Summary:
Consolidate LLDB_CODESIGN_IDENTITY logic in one place and use
SKIP_DEBUGSERVER, which can be set independently, to control
codesigning targets.
Currently, running cmake the first time in a clean directory, without
passing -DLLDB_CODESIGN_IDENTITY='', fails. However, subsequent runs
succeed. That's because LLDB_CODESIGN_IDENTITY gets added to the
CACHE after the initial test. To fix that, the default value must be
set before it's tested.
Here's the error produced on the first run:
CMake Error at tools/lldb/tools/debugserver/source/CMakeLists.txt:215
(add_custom_command):
No TARGET 'debugserver' has been created in this directory.
Differential Revision: https://reviews.llvm.org/D43432
Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/tools/debugserver/source/CMakeLists.txt
Modified: lldb/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=325442&r1=325441&r2=325442&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Sat Feb 17 11:17:21 2018
@@ -57,21 +57,6 @@ if (NOT LLDB_DISABLE_PYTHON)
add_subdirectory(scripts)
endif ()
-if(CMAKE_HOST_APPLE)
- if(LLDB_CODESIGN_IDENTITY)
-set(DEBUGSERVER_PATH $)
- else()
-execute_process(
- COMMAND xcode-select -p
- OUTPUT_VARIABLE XCODE_DEV_DIR)
-string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
-set(DEBUGSERVER_PATH
-
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
-set(SKIP_DEBUGSERVER True)
- endif()
- message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
-endif()
-
add_subdirectory(source)
add_subdirectory(tools)
Modified: lldb/trunk/tools/debugserver/source/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/CMakeLists.txt?rev=325442&r1=325441&r2=325442&view=diff
==
--- lldb/trunk/tools/debugserver/source/CMakeLists.txt (original)
+++ lldb/trunk/tools/debugserver/source/CMakeLists.txt Sat Feb 17 11:17:21 2018
@@ -95,6 +95,22 @@ set(lldbDebugserverCommonSources
add_library(lldbDebugserverCommon ${lldbDebugserverCommonSources})
+set(LLDB_CODESIGN_IDENTITY "lldb_codesign"
+ CACHE STRING "Identity used for code signing. Set to empty string to skip
the signing step.")
+
+if(NOT LLDB_CODESIGN_IDENTITY STREQUAL "")
+ set(DEBUGSERVER_PATH $)
+else()
+ execute_process(
+COMMAND xcode-select -p
+OUTPUT_VARIABLE XCODE_DEV_DIR)
+ string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+ set(DEBUGSERVER_PATH
+
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+ set(SKIP_DEBUGSERVER True)
+endif()
+message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
+
if (APPLE)
if(IOS)
find_library(BACKBOARD_LIBRARY BackBoardServices
@@ -187,15 +203,13 @@ if(IOS)
set(entitlements_xml
${CMAKE_CURRENT_SOURCE_DIR}/debugserver-entitlements.plist)
endif()
-set(LLDB_CODESIGN_IDENTITY "lldb_codesign"
- CACHE STRING "Identity used for code signing. Set to empty string to skip
the signing step.")
set(LLDB_USE_ENTITLEMENTS_Default On)
if("${LLDB_CODESIGN_IDENTITY}" STREQUAL "lldb_codesign")
set(LLDB_USE_ENTITLEMENTS_Default Off)
endif()
option(LLDB_USE_ENTITLEMENTS "Use entitlements when codesigning (Defaults Off
when using lldb_codesign identity, otherwise On)"
${LLDB_USE_ENTITLEMENTS_Default})
-if ("${LLDB_CODESIGN_IDENTITY}" STREQUAL "")
+if (SKIP_DEBUGSERVER)
if (CMAKE_HOST_APPLE)
# If we haven't built a signed debugserver, copy the one from the system.
add_custom_target(debugserver
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r325452 - Add DEBUGSERVER_PATH to the cache so it'll be available for tests.
Author: dhinton
Date: Sat Feb 17 15:06:15 2018
New Revision: 325452
URL: http://llvm.org/viewvc/llvm-project?rev=325452&view=rev
Log:
Add DEBUGSERVER_PATH to the cache so it'll be available for tests.
This fixed a problem caused by r325442.
Differential Revision: https://reviews.llvm.org/D43432
Modified:
lldb/trunk/tools/debugserver/source/CMakeLists.txt
Modified: lldb/trunk/tools/debugserver/source/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/CMakeLists.txt?rev=325452&r1=325451&r2=325452&view=diff
==
--- lldb/trunk/tools/debugserver/source/CMakeLists.txt (original)
+++ lldb/trunk/tools/debugserver/source/CMakeLists.txt Sat Feb 17 15:06:15 2018
@@ -99,14 +99,14 @@ set(LLDB_CODESIGN_IDENTITY "lldb_codesig
CACHE STRING "Identity used for code signing. Set to empty string to skip
the signing step.")
if(NOT LLDB_CODESIGN_IDENTITY STREQUAL "")
- set(DEBUGSERVER_PATH $)
+ set(DEBUGSERVER_PATH $ CACHE PATH "Path to
debugserver.")
else()
execute_process(
COMMAND xcode-select -p
OUTPUT_VARIABLE XCODE_DEV_DIR)
string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
set(DEBUGSERVER_PATH
-
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver"
CACHE PATH "Path to debugserver.")
set(SKIP_DEBUGSERVER True)
endif()
message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints
On Thu, Oct 26, 2017 at 3:00 PM, Greg Clayton via Phabricator < revi...@reviews.llvm.org> wrote: > clayborg added a comment. > > Each lldb.SBValue has accessors for the stuff in an execution context: > > `` > > lldb::SBTarget GetTarget(); > lldb::SBProcess GetProcess(); > lldb::SBThread GetThread(); > lldb::SBFrame GetFrame(); > > You could keep a global map of process ID to diagtool if you want? > > What are you thinking of using this for? > Part of the rational for using exe_ctx was to allow debugging multiple targets as the same time, but if these use different versions of clang, the diagtool map won't match. I'll try moving it from the function __dict__ to the exe_ctx and see if that works. thanks... > > > https://reviews.llvm.org/D36347 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints
On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner wrote: > Seems fine, it would be nice if the workflow could be improved a little > bit so that all you have to do is say `clangdiag break > —error=“-Wcovered-switch”` or something . I think that gives the most > intuitive usage for people, even it’s a bit harder to implement. > The idea was to break on actual diagnostics emitted, but if you want to break on diagnostic usage, i.e., when it was checked but not emitted, I suppose that's possible as well. diagtool doesn't produce a mapping for this, but it could be added -- assuming tablegen produced enough info in the .inc files to support it. I added the feature I'm using here a few months ago, which was an extension to what Alex added earlier. > > I also think user shouldn’t really have to concern themselves with > diagtool, it should all just be magic. I get why it’s easier to do this > way, but from the users perspective, having the commands map as closely as > possible to the thing the person wants to do and hiding implementation > details is a big win from a usability standpoint. > For the normal use case, i.e., clang/llvm developers that build both together, it will just work by magic, i.e., you just run enable/disable. The only problem is when you build out-of-tree. If you can suggest a way to find the correct location by examining the executable, I'd be happy to add it. > > We can iterate on it later though > I'm happy to keep hacking on it -- got plenty of time on my hands right now... And I get to learn more about lldb... > On Thu, Oct 26, 2017 at 2:38 PM Don Hinton via Phabricator < > revi...@reviews.llvm.org> wrote: > >> hintonda updated this revision to Diff 120492. >> hintonda added a comment. >> >> - Remove debugging print statement, and enhance help message. >> >> >> https://reviews.llvm.org/D36347 >> >> Files: >> utils/clangdiag.py >> >> ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints
On Thu, Oct 26, 2017 at 5:44 PM, Zachary Turner wrote: > > > On Thu, Oct 26, 2017 at 3:18 PM Don Hinton wrote: > >> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner >> wrote: >> >>> Seems fine, it would be nice if the workflow could be improved a little >>> bit so that all you have to do is say `clangdiag break >>> —error=“-Wcovered-switch”` or something . I think that gives the most >>> intuitive usage for people, even it’s a bit harder to implement. >>> >> >> The idea was to break on actual diagnostics emitted, but if you want to >> break on diagnostic usage, i.e., when it was checked but not emitted, I >> suppose that's possible as well. diagtool doesn't produce a mapping for >> this, but it could be added -- assuming tablegen produced enough info in >> the .inc files to support it. I added the feature I'm using here a few >> months ago, which was an extension to what Alex added earlier. >> > > That was my idea too. But still, wouldn't it be possible to say > `clangdiag break --error="-Wcovered-switch"` and then have it break only > when the -Wcovered-switch diagnostic is *emitted*? > Please give it a try, e.g., here are a few I tried: clangdiag enable covered-switch-default clangdiag enable c++11-compat You can't pass the "-W" part since argparse thinks it's an option (can probably fix that if it's a problem), and you must provide the entire name. You can get the available names from diagtool, e.g.: diagtool list-warnings Please let me know what you think, and thanks for suggesting it. > > The reason I keep using this syntax though is because clang developers > always think in terms of the warning names. If you want to find out why a > warning is being emitted amidst a spew of other warnings and errors, you > really want to be able to specify the name of the warning. > > Don't get me wrong though, I do think this is a nice feature, I'm just > thinking of ways to make it more compelling by looking at it from the clang > developer's perspective and how they will most likely want to use it. > > Also, I still think it should go in lldb, not in clang. That's kind of > exactly what the lldb/examples folder is for. > > That said, lgtm, but I'm still interested to see if the workflow can be > streamlined down the line. Perhaps after it gets checked in you can make a > PSA on cfe-dev@ and mention that you want people to try it out and offer > feedback ;-) > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39436: Add regex support to file (-f) and module (-s) breakpoint options.
I'll add tests if it looks like it'll be accepted, but based on the initial response, that doesn't seem likely. However, it was a good exercise and addressed the issues raised. thanks again for all the feedback... don On Mon, Oct 30, 2017 at 9:44 PM, Zachary Turner wrote: > Asking again, but why can’t this be done in th the script for clangdiag? > For example, there’s no tests for any of this in this patch. And it seems > likely that it will be rarely used anyway. So I’m still not convinced the > option-pollution and increased long term code maintenance burden of this > underutilized codepath is worth the benefit. > > Can you see if manually scanning for these files in python and then > setting breakpoints on the right set of files solves the problem? > > On Mon, Oct 30, 2017 at 9:00 PM Don Hinton via Phabricator < > revi...@reviews.llvm.org> wrote: > >> hintonda updated this revision to Diff 120933. >> hintonda added a comment. >> >> - Remove prefix and add options. >> >> >> https://reviews.llvm.org/D39436 >> >> Files: >> include/lldb/Utility/FileSpec.h >> source/Commands/CommandObjectBreakpoint.cpp >> source/Utility/FileSpec.cpp >> >> ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39436: Add regex support to file (-f) and module (-s) breakpoint options.
There have been a few suggestions that I could just use a script to solve
this "problem" -- poor startup performance of clangdiag.
However, this patch was not submitted to solve a particular problem. It
was submitted in response to Jim's suggestion:
On Mon, Oct 23, 2017 at 6:25 PM, Jim Ingham wrote:
> Yeah, that would be easy to implement from the command line, maybe add a
> --file-is-regex flag or something.
>
> From the SB API it would be better to have something like:
>
> SBFileList SBTarget.GetFileListMatchingRegex("regex")
>
> Please file an enhancement request for these of hack'em in if you're so
> motivated.
>
clangdiag was only provided as a motivating example.
As for the contention that this would be a little used option, I'd argue
the opposite.
I use regular expressions all the time, and I'm sure I'm not alone. Once
uses are given the choice of providing multiple '-f' and/or '-s' options
compare to a single, more powerful '-z' or '-Z' option, I'd bet most of
them would start using the new options exclusively. I certainly would.
On Mon, Oct 30, 2017 at 10:03 PM, Don Hinton wrote:
> I'll add tests if it looks like it'll be accepted, but based on the
> initial response, that doesn't seem likely.
>
> However, it was a good exercise and addressed the issues raised.
>
> thanks again for all the feedback...
> don
>
> On Mon, Oct 30, 2017 at 9:44 PM, Zachary Turner
> wrote:
>
>> Asking again, but why can’t this be done in th the script for clangdiag?
>> For example, there’s no tests for any of this in this patch. And it seems
>> likely that it will be rarely used anyway. So I’m still not convinced the
>> option-pollution and increased long term code maintenance burden of this
>> underutilized codepath is worth the benefit.
>>
>> Can you see if manually scanning for these files in python and then
>> setting breakpoints on the right set of files solves the problem?
>>
>> On Mon, Oct 30, 2017 at 9:00 PM Don Hinton via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> hintonda updated this revision to Diff 120933.
>>> hintonda added a comment.
>>>
>>> - Remove prefix and add options.
>>>
>>>
>>> https://reviews.llvm.org/D39436
>>>
>>> Files:
>>> include/lldb/Utility/FileSpec.h
>>> source/Commands/CommandObjectBreakpoint.cpp
>>> source/Utility/FileSpec.cpp
>>>
>>>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39436: Add regex support to file (-f) and module (-s) breakpoint options.
On Tue, Oct 31, 2017 at 8:22 AM, Zachary Turner wrote:
>
>
> On Tue, Oct 31, 2017 at 8:12 AM Don Hinton wrote:
>
>> There have been a few suggestions that I could just use a script to solve
>> this "problem" -- poor startup performance of clangdiag.
>>
>> However, this patch was not submitted to solve a particular problem. It
>> was submitted in response to Jim's suggestion:
>>
>> On Mon, Oct 23, 2017 at 6:25 PM, Jim Ingham wrote:
>>
>>> Yeah, that would be easy to implement from the command line, maybe add a
>>> --file-is-regex flag or something.
>>>
>>> From the SB API it would be better to have something like:
>>>
>>> SBFileList SBTarget.GetFileListMatchingRegex("regex")
>>>
>>> Please file an enhancement request for these of hack'em in if you're so
>>> motivated.
>>>
>>
>> clangdiag was only provided as a motivating example.
>>
>
> Fair point, I had forgotten about that. That said, I'm honestly still not
> that big of a fan. It's no secret that I have a higher bar than others
> for options and API additions, but to me the potential use this particular
> option + SB API would get is not sufficient to justify the long term
> maintenance burden associated with having it.
>
I'm not that familiar with the SB API part, but will investigate, and try
to come up with a better motivation.
Thanks again for the suggestions and feedback...
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39436: Add regex support to file (-f) and module (-s) breakpoint options.
Btw, is there a way to pass the '-m' option via the SB API? I'd like to
exclude matches in comments when using BreakpointCreateBySourceRegex.
On Tue, Oct 31, 2017 at 8:26 AM, Don Hinton wrote:
> On Tue, Oct 31, 2017 at 8:22 AM, Zachary Turner
> wrote:
>
>>
>>
>> On Tue, Oct 31, 2017 at 8:12 AM Don Hinton wrote:
>>
>>> There have been a few suggestions that I could just use a script to
>>> solve this "problem" -- poor startup performance of clangdiag.
>>>
>>> However, this patch was not submitted to solve a particular problem. It
>>> was submitted in response to Jim's suggestion:
>>>
>>> On Mon, Oct 23, 2017 at 6:25 PM, Jim Ingham wrote:
>>>
Yeah, that would be easy to implement from the command line, maybe add
a --file-is-regex flag or something.
From the SB API it would be better to have something like:
SBFileList SBTarget.GetFileListMatchingRegex("regex")
Please file an enhancement request for these of hack'em in if you're so
motivated.
>>>
>>> clangdiag was only provided as a motivating example.
>>>
>>
>> Fair point, I had forgotten about that. That said, I'm honestly still
>> not that big of a fan. It's no secret that I have a higher bar than
>> others for options and API additions, but to me the potential use this
>> particular option + SB API would get is not sufficient to justify the long
>> term maintenance burden associated with having it.
>>
>
> I'm not that familiar with the SB API part, but will investigate, and try
> to come up with a better motivation.
>
> Thanks again for the suggestions and feedback...
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
