[Lldb-commits] [lldb] r296427 - Add a comment to describe purpose of signal-filtering test
Author: eugene Date: Mon Feb 27 20:40:34 2017 New Revision: 296427 URL: http://llvm.org/viewvc/llvm-project?rev=296427&view=rev Log: Add a comment to describe purpose of signal-filtering test Modified: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py Modified: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py?rev=296427&r1=296426&r2=296427&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py Mon Feb 27 20:40:34 2017 @@ -1,3 +1,5 @@ +# This test makes sure that lldb-server supports and properly handles +# QPassSignals GDB protocol package. from __future__ import print_function import gdbremote_testcase ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r296412 - Ah, this was an early exit to leave built products around, it wasn't meant to
Author: jmolenda
Date: Mon Feb 27 17:31:29 2017
New Revision: 296412
URL: http://llvm.org/viewvc/llvm-project?rev=296412&view=rev
Log:
Ah, this was an early exit to leave built products around, it wasn't meant to
be checked in.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py?rev=296412&r1=296411&r2=296412&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
Mon Feb 27 17:31:29 2017
@@ -39,7 +39,6 @@ class TestMultipleSimultaneousDebuggers(
self.inferior_exe = os.path.join(os.getcwd(), "testprog")
self.buildDriver('testprog.cpp', self.inferior_exe)
self.addTearDownHook(lambda: os.remove(self.inferior_exe))
-sys.exit()
# check_call will raise a CalledProcessError if multi-process-driver doesn't
return
# exit code 0 to indicate success. We can let this exception go - the test
harness
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r296406 - update pbxproj to match cmake config, broken in r296335
Author: penryu
Date: Mon Feb 27 16:56:27 2017
New Revision: 296406
URL: http://llvm.org/viewvc/llvm-project?rev=296406&view=rev
Log:
update pbxproj to match cmake config, broken in r296335
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=296406&r1=296405&r2=296406&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Mon Feb 27 16:56:27 2017
@@ -131,7 +131,6 @@
255EFF741AFABA720069F277 /* LockFileBase.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 255EFF731AFABA720069F277 /* LockFileBase.cpp */;
};
255EFF761AFABA950069F277 /* LockFilePosix.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 255EFF751AFABA950069F277 /* LockFilePosix.cpp
*/; };
256CBDB41ADD0EFD00BC6CDC /* RegisterContextPOSIXCore_arm.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 256CBDB21ADD0EFD00BC6CDC /*
RegisterContextPOSIXCore_arm.cpp */; };
- 256CBDBA1ADD107200BC6CDC /* RegisterContextLinux_arm.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 256CBDB61ADD107200BC6CDC /*
RegisterContextLinux_arm.cpp */; };
256CBDBC1ADD107200BC6CDC /* RegisterContextLinux_mips64.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 256CBDB81ADD107200BC6CDC /*
RegisterContextLinux_mips64.cpp */; };
256CBDC01ADD11C000BC6CDC /* RegisterContextPOSIX_arm.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 256CBDBE1ADD11C000BC6CDC /*
RegisterContextPOSIX_arm.cpp */; };
2579065C1BD0488100178368 /* TCPSocket.cpp in Sources */ = {isa
= PBXBuildFile; fileRef = 2579065A1BD0488100178368 /* TCPSocket.cpp */; };
@@ -880,6 +879,7 @@
9A3576A8116E9AB700E8ED2F /* SBHostOS.h in Headers */ = {isa =
PBXBuildFile; fileRef = 9A3576A7116E9AB700E8ED2F /* SBHostOS.h */; settings =
{ATTRIBUTES = (Public, ); }; };
9A3576AA116E9AC700E8ED2F /* SBHostOS.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 9A3576A9116E9AC700E8ED2F /* SBHostOS.cpp */; };
9A4F35101368A51A00823F52 /* StreamAsynchronousIO.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = 9A4F350F1368A51A00823F52 /*
StreamAsynchronousIO.cpp */; };
+ 9A77AD541E64E2760025CE04 /* RegisterInfoPOSIX_arm.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 9A77AD501E64E24E0025CE04 /*
RegisterInfoPOSIX_arm.cpp */; };
9AC7038E117674FB0086C050 /* SBInstruction.h in Headers */ =
{isa = PBXBuildFile; fileRef = 9AC7038D117674EB0086C050 /* SBInstruction.h */;
settings = {ATTRIBUTES = (Public, ); }; };
9AC70390117675270086C050 /* SBInstructionList.h in Headers */ =
{isa = PBXBuildFile; fileRef = 9AC7038F117675270086C050 /* SBInstructionList.h
*/; settings = {ATTRIBUTES = (Public, ); }; };
9AC703AF117675410086C050 /* SBInstruction.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 9AC703AE117675410086C050 /* SBInstruction.cpp
*/; };
@@ -970,7 +970,6 @@
B2A58724143119D50092BFBA /* SBWatchpoint.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = B2A58723143119D50092BFBA /* SBWatchpoint.cpp */;
};
B2B7CCEB15D1BD6700EEFB57 /* CommandObjectWatchpointCommand.cpp
in Sources */ = {isa = PBXBuildFile; fileRef = B2B7CCEA15D1BD6600EEFB57 /*
CommandObjectWatchpointCommand.cpp */; };
B2B7CCF015D1C20F00EEFB57 /* WatchpointOptions.cpp in Sources */
= {isa = PBXBuildFile; fileRef = B2B7CCEF15D1C20F00EEFB57 /*
WatchpointOptions.cpp */; };
- B5EFAE861AE53B1D007059F3 /* RegisterContextFreeBSD_arm.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = B5EFAE841AE53B1D007059F3 /*
RegisterContextFreeBSD_arm.cpp */; };
E769331C1A94D15400C73337 /* lldb-gdbserver.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 26D6F3F4183E7F9300194858 /* lldb-gdbserver.cpp
*/; };
E769331E1A94D18100C73337 /* lldb-server.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = E769331D1A94D18100C73337 /* lldb-server.cpp */;
};
E7723D441AC4A7FB002BA082 /* RegisterContextPOSIXCore_arm64.cpp
in Sources */ = {isa = PBXBuildFile; fileRef = E7723D421AC4A7FB002BA082 /*
RegisterContextPOSIXCore_arm64.cpp */; };
@@ -1365,8 +1364,6 @@
255EFF751AFABA950069F277 /* LockFilePosix.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = LockFilePosix.cpp; sourceTree = ""; };
256CBDB21ADD0EFD00BC6CDC /* RegisterContextPOSIXCore_arm.cpp */
= {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; path = RegisterContextPOSIXCore_arm.cpp; sourceTree =
""; };
256CBDB31ADD0EFD00BC6CDC /* RegisterContextPOSIXCore_arm.h */ =
{isa = PBXFileRefer
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
Having library functions that don't return good errors seems like such an obvious failing that it shouldn't be hard to motivate fixing that. Then our logging can go in the wrapper classes, using those errors. That seems like a pattern that solves the "don't duplicate code" problem and the "lldb needs more logging" problems nicely. Jim > On Feb 27, 2017, at 12:00 PM, Zachary Turner wrote: > > Oh that wasn't in response to the comment about wrapper classes, that was > just a general comment about the fact that we lose logging by moving to > LLVM's implementation at all. If we have our own implementation, we could in > theory log at various stages of the mmaping process, but by moving to a > library implementation we can only log before or after. > > On Mon, Feb 27, 2017 at 11:55 AM Jim Ingham wrote: > > > On Feb 27, 2017, at 11:49 AM, Zachary Turner wrote: > > > > There may be some cases where we're no longer mmaping where we used to, but > > looking at LLVM's implementation, that would only happen if the file is > > fairly small, and there's a comment in LLVM explaining why they don't mmap > > small files. So I think that's actually an improvement for LLDB (although > > I doubt we are frequently mapping very small files, so it might be a non > > issue). > > > > You are correct that we lose some logging this way, but in exchange we get > > better tested code. The code in question that we lose though is basically > > just the call to mmap and the setup to prepare that call. As long as we > > have the return code from mmap, we should be able to log the error just as > > gracefully. Granted, the LLVM code doesn't return an error code right now, > > but it seems like a worthy improvement. > > > > I'm not sure where the right balance is between facilitating post-mortem > > diagnostics and reducing the amount of problems that happen in the first > > place, but I feel kind of dirty duplicating code just so that we can add > > logging. Maybe there's a case to be made for adding logging hooks into > > LLVM. > > Why do wrapper classes mean you get significantly less well tested code? If > they are just to support logging, you really only need to know that the > values are passed correctly, which is easy to test, and then you could test > that the logging is correct, though we don't currently do logging tests for > the most part. > > Jim > > > > > > > > On Mon, Feb 27, 2017 at 11:00 AM Jim Ingham wrote: > > I worry about stripping out the wrappers, because there are some > > differences in how lldb operates from llvm that I don't think we want to > > push down into llvm - in this case I'm thinking particularly about logging. > > DataBufferMemoryMap did a bunch of logging, which presumably would get > > lost if you just went directly to the llvm classes. Most of the tools that > > build out of the llvm toolset are one-pass tools, and reproducing problems > > with their operation is generally not terribly hard. So having a rich > > logging feature is not all that necessary, and the burden of adding it to > > the code not worth the benefit. But lldb is much more state dependent, and > > is exposed to a wider variety of the vagaries of system behavior, and being > > both an interactive tool and the API's for GUI debuggers, has a wider and > > more unpredictable array of of use cases. Having good logging has saved my > > day many and many's the time over the years, and I don't want to lose that. > > > > So while I don't have any objection to changing the backing implementation, > > I still see value in the wrapper classes. > > > > You say LLVM memory buffers can be heap or mmap, but presumably when used > > by what used to be DataBufferMemoryMap they are using the memory map > > version, right? Still seems useful to have the class name say what the > > thing is. > > > > Jim > > > > > On Feb 27, 2017, at 10:40 AM, Zachary Turner wrote: > > > > > > I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not > > > necessarily mmap'ed. It might be mmap'ed and it might not be. Depends > > > on various factors such as whether you specify the IsVolatile flag, how > > > big the file is, and maybe a few other things. > > > > > > After this change we have DataBufferLLVM and DataBufferHeap. But it > > > turns out an LLVM MemoryBuffer can also be backed by the heap, which now > > > makes DataBufferHeap redundant as well. So I think longer term we might > > > be able to get rid of all of LLDB's DataBuffer stuff entirely, and > > > everything will just use llvm::MemoryBuffer directly. > > > > > > What do you think? > > > > > > On Mon, Feb 27, 2017 at 10:36 AM Jim Ingham wrote: > > > This is kind of after the fact, but why didn't we reuse > > > DataBufferMemoryMap for the Memory Map data buffer that now happens to be > > > backed by an LLVM implementation? DataBufferLLVM doesn't really tell > > > anybody what the thing does w/o looking up t
[Lldb-commits] [PATCH] D30402: Modernize Enable/DisableLogChannel interface a bit
zturner added inline comments.
Comment at: include/lldb/Interpreter/Args.h:196-197
+ llvm::ArrayRef GetArgumentArrayRef() const {
+return {static_cast(m_argv.data()),
+m_argv.size() - 1};
+ }
can this be written `return makeArrayRef(m_argv).drop_back();`?
Comment at: source/API/SBDebugger.cpp:1129
+++len;
+ return {categories, len};
+}
`makeArrayRef(categories, len)` again seems more readable.
Comment at: source/Core/Log.cpp:74-80
+auto cat = llvm::find_if(
+entry.second.channel.categories,
+[&](const Log::Category &c) { return c.name.equals_lower(category); });
if (cat != entry.second.channel.categories.end()) {
flags |= cat->flag;
continue;
}
How about
```
bool exists = llvm::any(entry.second.channel.categories,
[&](const Log::Category &c) { return c.name.equals_lower(category); }));
if (exists) {
...
}
```
Comment at: unittests/Interpreter/TestArgs.cpp:174
+ Args args("foo bar");
+ llvm::ArrayRef ref = args.GetArgumentArrayRef();
+ ASSERT_EQ(2u, ref.size());
I'd probably use `auto` here since the function indicates that it's returning
an `ArrayRef`. I don't feel strongly though.
https://reviews.llvm.org/D30402
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
Oh that wasn't in response to the comment about wrapper classes, that was just a general comment about the fact that we lose logging by moving to LLVM's implementation at all. If we have our own implementation, we could in theory log at various stages of the mmaping process, but by moving to a library implementation we can only log before or after. On Mon, Feb 27, 2017 at 11:55 AM Jim Ingham wrote: > > > On Feb 27, 2017, at 11:49 AM, Zachary Turner wrote: > > > > There may be some cases where we're no longer mmaping where we used to, > but looking at LLVM's implementation, that would only happen if the file is > fairly small, and there's a comment in LLVM explaining why they don't mmap > small files. So I think that's actually an improvement for LLDB (although > I doubt we are frequently mapping very small files, so it might be a non > issue). > > > > You are correct that we lose some logging this way, but in exchange we > get better tested code. The code in question that we lose though is > basically just the call to mmap and the setup to prepare that call. As > long as we have the return code from mmap, we should be able to log the > error just as gracefully. Granted, the LLVM code doesn't return an error > code right now, but it seems like a worthy improvement. > > > > I'm not sure where the right balance is between facilitating post-mortem > diagnostics and reducing the amount of problems that happen in the first > place, but I feel kind of dirty duplicating code just so that we can add > logging. Maybe there's a case to be made for adding logging hooks into > LLVM. > > Why do wrapper classes mean you get significantly less well tested code? > If they are just to support logging, you really only need to know that the > values are passed correctly, which is easy to test, and then you could test > that the logging is correct, though we don't currently do logging tests for > the most part. > > Jim > > > > > > > > On Mon, Feb 27, 2017 at 11:00 AM Jim Ingham wrote: > > I worry about stripping out the wrappers, because there are some > differences in how lldb operates from llvm that I don't think we want to > push down into llvm - in this case I'm thinking particularly about > logging. DataBufferMemoryMap did a bunch of logging, which presumably > would get lost if you just went directly to the llvm classes. Most of the > tools that build out of the llvm toolset are one-pass tools, and > reproducing problems with their operation is generally not terribly hard. > So having a rich logging feature is not all that necessary, and the burden > of adding it to the code not worth the benefit. But lldb is much more > state dependent, and is exposed to a wider variety of the vagaries of > system behavior, and being both an interactive tool and the API's for GUI > debuggers, has a wider and more unpredictable array of of use cases. > Having good logging has saved my day many and many's the time over the > years, and I don't want to lose that. > > > > So while I don't have any objection to changing the backing > implementation, I still see value in the wrapper classes. > > > > You say LLVM memory buffers can be heap or mmap, but presumably when > used by what used to be DataBufferMemoryMap they are using the memory map > version, right? Still seems useful to have the class name say what the > thing is. > > > > Jim > > > > > On Feb 27, 2017, at 10:40 AM, Zachary Turner > wrote: > > > > > > I didn't refer to mmaping in the name because LLVM's MemoryBuffer is > not necessarily mmap'ed. It might be mmap'ed and it might not be. Depends > on various factors such as whether you specify the IsVolatile flag, how big > the file is, and maybe a few other things. > > > > > > After this change we have DataBufferLLVM and DataBufferHeap. But it > turns out an LLVM MemoryBuffer can also be backed by the heap, which now > makes DataBufferHeap redundant as well. So I think longer term we might be > able to get rid of all of LLDB's DataBuffer stuff entirely, and everything > will just use llvm::MemoryBuffer directly. > > > > > > What do you think? > > > > > > On Mon, Feb 27, 2017 at 10:36 AM Jim Ingham wrote: > > > This is kind of after the fact, but why didn't we reuse > DataBufferMemoryMap for the Memory Map data buffer that now happens to be > backed by an LLVM implementation? DataBufferLLVM doesn't really tell > anybody what the thing does w/o looking up the implementation. > > > > > > Jim > > > > > > > > > > On Feb 27, 2017, at 2:56 AM, Pavel Labath via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > > > > > I was thinking of a simple test like "call get on an existing file > and > > > > make sure it returns something reasonable" and "call get on a > > > > non-existing file and make sure it returns null". This is a very thin > > > > wrapper over over the llvm code, so I don't insist on it though... > > > > > > > > On 24 February 2017 at 15:18, Zachary Turner > wrote: > > > >> I left out unit tests
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
> On Feb 27, 2017, at 11:49 AM, Zachary Turner wrote: > > There may be some cases where we're no longer mmaping where we used to, but > looking at LLVM's implementation, that would only happen if the file is > fairly small, and there's a comment in LLVM explaining why they don't mmap > small files. So I think that's actually an improvement for LLDB (although I > doubt we are frequently mapping very small files, so it might be a non issue). > > You are correct that we lose some logging this way, but in exchange we get > better tested code. The code in question that we lose though is basically > just the call to mmap and the setup to prepare that call. As long as we have > the return code from mmap, we should be able to log the error just as > gracefully. Granted, the LLVM code doesn't return an error code right now, > but it seems like a worthy improvement. > > I'm not sure where the right balance is between facilitating post-mortem > diagnostics and reducing the amount of problems that happen in the first > place, but I feel kind of dirty duplicating code just so that we can add > logging. Maybe there's a case to be made for adding logging hooks into LLVM. Why do wrapper classes mean you get significantly less well tested code? If they are just to support logging, you really only need to know that the values are passed correctly, which is easy to test, and then you could test that the logging is correct, though we don't currently do logging tests for the most part. Jim > > > On Mon, Feb 27, 2017 at 11:00 AM Jim Ingham wrote: > I worry about stripping out the wrappers, because there are some differences > in how lldb operates from llvm that I don't think we want to push down into > llvm - in this case I'm thinking particularly about logging. > DataBufferMemoryMap did a bunch of logging, which presumably would get lost > if you just went directly to the llvm classes. Most of the tools that build > out of the llvm toolset are one-pass tools, and reproducing problems with > their operation is generally not terribly hard. So having a rich logging > feature is not all that necessary, and the burden of adding it to the code > not worth the benefit. But lldb is much more state dependent, and is exposed > to a wider variety of the vagaries of system behavior, and being both an > interactive tool and the API's for GUI debuggers, has a wider and more > unpredictable array of of use cases. Having good logging has saved my day > many and many's the time over the years, and I don't want to lose that. > > So while I don't have any objection to changing the backing implementation, I > still see value in the wrapper classes. > > You say LLVM memory buffers can be heap or mmap, but presumably when used by > what used to be DataBufferMemoryMap they are using the memory map version, > right? Still seems useful to have the class name say what the thing is. > > Jim > > > On Feb 27, 2017, at 10:40 AM, Zachary Turner wrote: > > > > I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not > > necessarily mmap'ed. It might be mmap'ed and it might not be. Depends on > > various factors such as whether you specify the IsVolatile flag, how big > > the file is, and maybe a few other things. > > > > After this change we have DataBufferLLVM and DataBufferHeap. But it turns > > out an LLVM MemoryBuffer can also be backed by the heap, which now makes > > DataBufferHeap redundant as well. So I think longer term we might be able > > to get rid of all of LLDB's DataBuffer stuff entirely, and everything will > > just use llvm::MemoryBuffer directly. > > > > What do you think? > > > > On Mon, Feb 27, 2017 at 10:36 AM Jim Ingham wrote: > > This is kind of after the fact, but why didn't we reuse DataBufferMemoryMap > > for the Memory Map data buffer that now happens to be backed by an LLVM > > implementation? DataBufferLLVM doesn't really tell anybody what the thing > > does w/o looking up the implementation. > > > > Jim > > > > > > > On Feb 27, 2017, at 2:56 AM, Pavel Labath via lldb-commits > > > wrote: > > > > > > I was thinking of a simple test like "call get on an existing file and > > > make sure it returns something reasonable" and "call get on a > > > non-existing file and make sure it returns null". This is a very thin > > > wrapper over over the llvm code, so I don't insist on it though... > > > > > > On 24 February 2017 at 15:18, Zachary Turner wrote: > > >> I left out unit tests since we'd essentially be duplicating the unit > > >> tests > > >> of MemoryBuffer, and because it involves the file system (also this is > > >> temporary code until DataBuffer stuff goes away). Lmk if you disagree > > >> though > > >> On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator > > >> wrote: > > >>> > > >>> labath added a comment. > > >>> > > >>> I am not sure if this is a voting situation, but I agree with what > > >>> Zachary > > >>> said abov
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
There may be some cases where we're no longer mmaping where we used to, but looking at LLVM's implementation, that would only happen if the file is fairly small, and there's a comment in LLVM explaining why they don't mmap small files. So I think that's actually an improvement for LLDB (although I doubt we are frequently mapping very small files, so it might be a non issue). You are correct that we lose some logging this way, but in exchange we get better tested code. The code in question that we lose though is basically just the call to mmap and the setup to prepare that call. As long as we have the return code from mmap, we should be able to log the error just as gracefully. Granted, the LLVM code doesn't return an error code right now, but it seems like a worthy improvement. I'm not sure where the right balance is between facilitating post-mortem diagnostics and reducing the amount of problems that happen in the first place, but I feel kind of dirty duplicating code just so that we can add logging. Maybe there's a case to be made for adding logging hooks into LLVM. On Mon, Feb 27, 2017 at 11:00 AM Jim Ingham wrote: > I worry about stripping out the wrappers, because there are some > differences in how lldb operates from llvm that I don't think we want to > push down into llvm - in this case I'm thinking particularly about > logging. DataBufferMemoryMap did a bunch of logging, which presumably > would get lost if you just went directly to the llvm classes. Most of the > tools that build out of the llvm toolset are one-pass tools, and > reproducing problems with their operation is generally not terribly hard. > So having a rich logging feature is not all that necessary, and the burden > of adding it to the code not worth the benefit. But lldb is much more > state dependent, and is exposed to a wider variety of the vagaries of > system behavior, and being both an interactive tool and the API's for GUI > debuggers, has a wider and more unpredictable array of of use cases. > Having good logging has saved my day many and many's the time over the > years, and I don't want to lose that. > > So while I don't have any objection to changing the backing > implementation, I still see value in the wrapper classes. > > You say LLVM memory buffers can be heap or mmap, but presumably when used > by what used to be DataBufferMemoryMap they are using the memory map > version, right? Still seems useful to have the class name say what the > thing is. > > Jim > > > On Feb 27, 2017, at 10:40 AM, Zachary Turner wrote: > > > > I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not > necessarily mmap'ed. It might be mmap'ed and it might not be. Depends on > various factors such as whether you specify the IsVolatile flag, how big > the file is, and maybe a few other things. > > > > After this change we have DataBufferLLVM and DataBufferHeap. But it > turns out an LLVM MemoryBuffer can also be backed by the heap, which now > makes DataBufferHeap redundant as well. So I think longer term we might be > able to get rid of all of LLDB's DataBuffer stuff entirely, and everything > will just use llvm::MemoryBuffer directly. > > > > What do you think? > > > > On Mon, Feb 27, 2017 at 10:36 AM Jim Ingham wrote: > > This is kind of after the fact, but why didn't we reuse > DataBufferMemoryMap for the Memory Map data buffer that now happens to be > backed by an LLVM implementation? DataBufferLLVM doesn't really tell > anybody what the thing does w/o looking up the implementation. > > > > Jim > > > > > > > On Feb 27, 2017, at 2:56 AM, Pavel Labath via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > > > I was thinking of a simple test like "call get on an existing file and > > > make sure it returns something reasonable" and "call get on a > > > non-existing file and make sure it returns null". This is a very thin > > > wrapper over over the llvm code, so I don't insist on it though... > > > > > > On 24 February 2017 at 15:18, Zachary Turner > wrote: > > >> I left out unit tests since we'd essentially be duplicating the unit > tests > > >> of MemoryBuffer, and because it involves the file system (also this is > > >> temporary code until DataBuffer stuff goes away). Lmk if you disagree > though > > >> On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator > > >> wrote: > > >>> > > >>> labath added a comment. > > >>> > > >>> I am not sure if this is a voting situation, but I agree with what > Zachary > > >>> said above. > > >>> > > >>> Since we're already speaking about tests, it looks like the new > > >>> DataBufferLLVM class could use a unit test or two, just so we get in > the > > >>> habit of writing those. > > >>> > > >>> > > >>> https://reviews.llvm.org/D30054 > > >>> > > >>> > > >>> > > >> > > > ___ > > > lldb-commits mailing list > > > lldb-commits@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > >
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
I worry about stripping out the wrappers, because there are some differences in how lldb operates from llvm that I don't think we want to push down into llvm - in this case I'm thinking particularly about logging. DataBufferMemoryMap did a bunch of logging, which presumably would get lost if you just went directly to the llvm classes. Most of the tools that build out of the llvm toolset are one-pass tools, and reproducing problems with their operation is generally not terribly hard. So having a rich logging feature is not all that necessary, and the burden of adding it to the code not worth the benefit. But lldb is much more state dependent, and is exposed to a wider variety of the vagaries of system behavior, and being both an interactive tool and the API's for GUI debuggers, has a wider and more unpredictable array of of use cases. Having good logging has saved my day many and many's the time over the years, and I don't want to lose that. So while I don't have any objection to changing the backing implementation, I still see value in the wrapper classes. You say LLVM memory buffers can be heap or mmap, but presumably when used by what used to be DataBufferMemoryMap they are using the memory map version, right? Still seems useful to have the class name say what the thing is. Jim > On Feb 27, 2017, at 10:40 AM, Zachary Turner wrote: > > I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not > necessarily mmap'ed. It might be mmap'ed and it might not be. Depends on > various factors such as whether you specify the IsVolatile flag, how big the > file is, and maybe a few other things. > > After this change we have DataBufferLLVM and DataBufferHeap. But it turns > out an LLVM MemoryBuffer can also be backed by the heap, which now makes > DataBufferHeap redundant as well. So I think longer term we might be able to > get rid of all of LLDB's DataBuffer stuff entirely, and everything will just > use llvm::MemoryBuffer directly. > > What do you think? > > On Mon, Feb 27, 2017 at 10:36 AM Jim Ingham wrote: > This is kind of after the fact, but why didn't we reuse DataBufferMemoryMap > for the Memory Map data buffer that now happens to be backed by an LLVM > implementation? DataBufferLLVM doesn't really tell anybody what the thing > does w/o looking up the implementation. > > Jim > > > > On Feb 27, 2017, at 2:56 AM, Pavel Labath via lldb-commits > > wrote: > > > > I was thinking of a simple test like "call get on an existing file and > > make sure it returns something reasonable" and "call get on a > > non-existing file and make sure it returns null". This is a very thin > > wrapper over over the llvm code, so I don't insist on it though... > > > > On 24 February 2017 at 15:18, Zachary Turner wrote: > >> I left out unit tests since we'd essentially be duplicating the unit tests > >> of MemoryBuffer, and because it involves the file system (also this is > >> temporary code until DataBuffer stuff goes away). Lmk if you disagree > >> though > >> On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator > >> wrote: > >>> > >>> labath added a comment. > >>> > >>> I am not sure if this is a voting situation, but I agree with what Zachary > >>> said above. > >>> > >>> Since we're already speaking about tests, it looks like the new > >>> DataBufferLLVM class could use a unit test or two, just so we get in the > >>> habit of writing those. > >>> > >>> > >>> https://reviews.llvm.org/D30054 > >>> > >>> > >>> > >> > > ___ > > lldb-commits mailing list > > lldb-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not necessarily mmap'ed. It might be mmap'ed and it might not be. Depends on various factors such as whether you specify the IsVolatile flag, how big the file is, and maybe a few other things. After this change we have DataBufferLLVM and DataBufferHeap. But it turns out an LLVM MemoryBuffer can also be backed by the heap, which now makes DataBufferHeap redundant as well. So I think longer term we might be able to get rid of all of LLDB's DataBuffer stuff entirely, and everything will just use llvm::MemoryBuffer directly. What do you think? On Mon, Feb 27, 2017 at 10:36 AM Jim Ingham wrote: > This is kind of after the fact, but why didn't we reuse > DataBufferMemoryMap for the Memory Map data buffer that now happens to be > backed by an LLVM implementation? DataBufferLLVM doesn't really tell > anybody what the thing does w/o looking up the implementation. > > Jim > > > > On Feb 27, 2017, at 2:56 AM, Pavel Labath via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > I was thinking of a simple test like "call get on an existing file and > > make sure it returns something reasonable" and "call get on a > > non-existing file and make sure it returns null". This is a very thin > > wrapper over over the llvm code, so I don't insist on it though... > > > > On 24 February 2017 at 15:18, Zachary Turner wrote: > >> I left out unit tests since we'd essentially be duplicating the unit > tests > >> of MemoryBuffer, and because it involves the file system (also this is > >> temporary code until DataBuffer stuff goes away). Lmk if you disagree > though > >> On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator > >> wrote: > >>> > >>> labath added a comment. > >>> > >>> I am not sure if this is a voting situation, but I agree with what > Zachary > >>> said above. > >>> > >>> Since we're already speaking about tests, it looks like the new > >>> DataBufferLLVM class could use a unit test or two, just so we get in > the > >>> habit of writing those. > >>> > >>> > >>> https://reviews.llvm.org/D30054 > >>> > >>> > >>> > >> > > ___ > > lldb-commits mailing list > > lldb-commits@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
This is kind of after the fact, but why didn't we reuse DataBufferMemoryMap for the Memory Map data buffer that now happens to be backed by an LLVM implementation? DataBufferLLVM doesn't really tell anybody what the thing does w/o looking up the implementation. Jim > On Feb 27, 2017, at 2:56 AM, Pavel Labath via lldb-commits > wrote: > > I was thinking of a simple test like "call get on an existing file and > make sure it returns something reasonable" and "call get on a > non-existing file and make sure it returns null". This is a very thin > wrapper over over the llvm code, so I don't insist on it though... > > On 24 February 2017 at 15:18, Zachary Turner wrote: >> I left out unit tests since we'd essentially be duplicating the unit tests >> of MemoryBuffer, and because it involves the file system (also this is >> temporary code until DataBuffer stuff goes away). Lmk if you disagree though >> On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator >> wrote: >>> >>> labath added a comment. >>> >>> I am not sure if this is a voting situation, but I agree with what Zachary >>> said above. >>> >>> Since we're already speaking about tests, it looks like the new >>> DataBufferLLVM class could use a unit test or two, just so we get in the >>> habit of writing those. >>> >>> >>> https://reviews.llvm.org/D30054 >>> >>> >>> >> > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r296360 - Support NetBSD Thread ID in lldb-server tests
Author: kamil
Date: Mon Feb 27 11:52:48 2017
New Revision: 296360
URL: http://llvm.org/viewvc/llvm-project?rev=296360&view=rev
Log:
Support NetBSD Thread ID in lldb-server tests
Summary:
Native Thread ID is retrieved with _lwp_self() on NetBSD.
The returned value is of type int32_t, but for consistency with other Operating
Systems cast it to uint64_t.
Sponsored by
Reviewers: joerg, labath, clayborg, emaste
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30374
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/exit-code/main.cpp
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/exit-code/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/exit-code/main.cpp?rev=296360&r1=296359&r2=296360&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/exit-code/main.cpp
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/exit-code/main.cpp
Mon Feb 27 11:52:48 2017
@@ -18,6 +18,8 @@ __OSX_AVAILABLE_STARTING(__MAC_10_6, __I
int pthread_threadid_np(pthread_t, __uint64_t *);
#elif defined(__linux__)
#include
+#elif defined(__NetBSD__)
+#include
#endif
static const char *const RETVAL_PREFIX = "retval:";
@@ -62,6 +64,9 @@ static void print_thread_id() {
#elif defined(__linux__)
// This is a call to gettid() via syscall.
printf("%" PRIx64, static_cast(syscall(__NR_gettid)));
+#elif defined(__NetBSD__)
+ // Technically lwpid_t is 32-bit signed integer
+ printf("%" PRIx64, static_cast(_lwp_self()));
#else
printf("{no-tid-support}");
#endif
Modified: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp?rev=296360&r1=296359&r2=296360&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp Mon
Feb 27 11:52:48 2017
@@ -27,6 +27,8 @@ __OSX_AVAILABLE_STARTING(__MAC_10_6, __I
int pthread_threadid_np(pthread_t, __uint64_t *);
#elif defined(__linux__)
#include
+#elif defined(__NetBSD__)
+#include
#endif
static const char *const RETVAL_PREFIX = "retval:";
@@ -71,6 +73,9 @@ static void print_thread_id() {
#elif defined(__linux__)
// This is a call to gettid() via syscall.
printf("%" PRIx64, static_cast(syscall(__NR_gettid)));
+#elif defined(__NetBSD__)
+ // Technically lwpid_t is 32-bit signed integer
+ printf("%" PRIx64, static_cast(_lwp_self()));
#else
printf("{no-tid-support}");
#endif
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D30410: testsuite/android: build test executables with the android ndk directly
labath created this revision. Herald added a subscriber: srhines. This teaches the test makefiles about the Android NDK, so we are able to run the tests without first going through the make_standalone_toolchain script. The motivation for this is the ability to run both libc++ and libstdc++ tests together, which previously was not possible because make_standalone_toolchain bakes in the STL to use during toolchain creation time. The support for this is not present yet -- this change only make sure we don't regress for existing funcionality (gcc w/ libstdc++). Clang and libc++ support will be added later. https://reviews.llvm.org/D30410 Files: packages/Python/lldbsuite/test/make/Android.rules packages/Python/lldbsuite/test/make/Makefile.rules Index: packages/Python/lldbsuite/test/make/Makefile.rules === --- packages/Python/lldbsuite/test/make/Makefile.rules +++ packages/Python/lldbsuite/test/make/Makefile.rules @@ -35,7 +35,7 @@ # If TRIPLE is not defined try to set the ARCH, CC, CFLAGS, and more # from the triple alone #-- -TRIPLE_CFLAGS := +ARCH_CFLAGS := ifneq "$(TRIPLE)" "" triple_space = $(subst -, ,$(TRIPLE)) ARCH =$(word 1, $(triple_space)) @@ -52,18 +52,21 @@ ifeq "$(TRIPLE_VERSION)" "" TRIPLE_VERSION =$(shell echo $(notdir $(SDKROOT)) | sed -e 's/.*\([0-9]\.[0-9]\).*/\1/') endif - TRIPLE_CFLAGS :=-mios-version-min=$(TRIPLE_VERSION) -isysroot "$(SDKROOT)" + ARCH_CFLAGS :=-mios-version-min=$(TRIPLE_VERSION) -isysroot "$(SDKROOT)" else SDKROOT = $(shell xcrun --sdk iphonesimulator --show-sdk-path) ifeq "$(TRIPLE_VERSION)" "" TRIPLE_VERSION =$(shell echo $(notdir $(SDKROOT)) | sed -e 's/.*\([0-9]\.[0-9]\).*/\1/') endif - TRIPLE_CFLAGS :=-mios-simulator-version-min=$(TRIPLE_VERSION) -isysroot "$(SDKROOT)" + ARCH_CFLAGS :=-mios-simulator-version-min=$(TRIPLE_VERSION) -isysroot "$(SDKROOT)" endif endif endif endif endif +ifeq "$(OS)" "Android" + include $(THIS_FILE_DIR)/Android.rules +endif #-- # If OS is not defined, use 'uname -s' to determine the OS name. @@ -199,13 +202,13 @@ CFLAGS += $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include endif -CFLAGS += -include $(THIS_FILE_DIR)test_common.h $(TRIPLE_CFLAGS) +CFLAGS += -include $(THIS_FILE_DIR)test_common.h $(ARCH_CFLAGS) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) $(TRIPLE_CFLAGS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) $(ARCH_CFLAGS) else - CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) $(TRIPLE_CFLAGS) + CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) $(ARCH_CFLAGS) endif ifeq "$(MAKE_DWO)" "YES" @@ -221,7 +224,7 @@ CXXFLAGS += $(subst -fmodules,, $(CFLAGS)) LD = $(CC) LDFLAGS ?= $(CFLAGS) -LDFLAGS += $(LD_EXTRAS) +LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS) ifeq (,$(filter $(OS), Windows_NT Android)) ifneq (,$(filter YES,$(ENABLE_THREADS))) LDFLAGS += -pthread Index: packages/Python/lldbsuite/test/make/Android.rules === --- /dev/null +++ packages/Python/lldbsuite/test/make/Android.rules @@ -0,0 +1,36 @@ +NDK_ROOT := $(shell dirname $(CC))/../../../../.. +NDK_ROOT := $(realpath $(NDK_ROOT)) + +ifeq "$(findstring $(ARCH), aarch64 x86_64)" "$(ARCH)" + # lowest 64-bit API level + API_LEVEL := 21 +else ifeq "$(ARCH)" "i386" + # clone(2) declaration is present only since this api level + API_LEVEL := 17 +else + # lowest supported 32-bit API level + API_LEVEL := 9 +endif + +ifeq "$(ARCH)" "arm" + STL_ARCH := armeabi-v7a + ARCH_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -marm +else ifeq "$(ARCH)" "aarch64" + SYSROOT_ARCH := arm64 + STL_ARCH := arm64-v8a +else ifeq "$(ARCH)" "i386" + SYSROOT_ARCH := x86 + STL_ARCH := x86 +else + SYSROOT_ARCH := $(ARCH) + STL_ARCH := $(ARCH) +endif + +ARCH_CFLAGS += \ + --sysroot=$(NDK_ROOT)/platforms/android-$(API_LEVEL)/arch-$(SYSROOT_ARCH) \ + -isystem $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.9/include \ + -isystem $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.9/libs/$(STL_ARCH)/include \ + -isystem $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.9/include/backward +ARCH_LDFLAGS += -lm \ + $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.9/libs/$(STL_ARCH)/libgnustl_static.a \ + --sysroot=$(NDK_ROOT)/platforms/android-$(API_LEVEL)/arch-$(SYSROOT_ARCH) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27126: Merge Linux and FreeBSD arm register contexts
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296335: Merge Linux and FreeBSD arm register contexts
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D27126?vs=79287&id=89866#toc
Repository:
rL LLVM
https://reviews.llvm.org/D27126
Files:
lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Utility/RegisterContextFreeBSD_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextFreeBSD_arm.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLinux_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLinux_arm.h
lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.h
lldb/trunk/source/Plugins/Process/elf-core/ThreadElfCore.cpp
Index: lldb/trunk/source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- lldb/trunk/source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ lldb/trunk/source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -14,15 +14,14 @@
#include "lldb/Target/Target.h"
#include "lldb/Target/Unwind.h"
-#include "Plugins/Process/Utility/RegisterContextFreeBSD_arm.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
-#include "Plugins/Process/Utility/RegisterContextLinux_arm.h"
#include "Plugins/Process/Utility/RegisterContextLinux_i386.h"
#include "Plugins/Process/Utility/RegisterContextLinux_s390x.h"
#include "Plugins/Process/Utility/RegisterContextLinux_x86_64.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
#include "ProcessElfCore.h"
#include "RegisterContextPOSIXCore_arm.h"
@@ -88,7 +87,7 @@
reg_interface = new RegisterInfoPOSIX_arm64(arch);
break;
case llvm::Triple::arm:
-reg_interface = new RegisterContextFreeBSD_arm(arch);
+reg_interface = new RegisterInfoPOSIX_arm(arch);
break;
case llvm::Triple::ppc:
reg_interface = new RegisterContextFreeBSD_powerpc32(arch);
@@ -114,7 +113,7 @@
case llvm::Triple::Linux: {
switch (arch.GetMachine()) {
case llvm::Triple::arm:
-reg_interface = new RegisterContextLinux_arm(arch);
+reg_interface = new RegisterInfoPOSIX_arm(arch);
break;
case llvm::Triple::aarch64:
reg_interface = new RegisterInfoPOSIX_arm64(arch);
Index: lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
===
--- lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
+++ lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
@@ -18,11 +18,11 @@
// Project includes
#include "FreeBSDThread.h"
#include "POSIXStopInfo.h"
-#include "Plugins/Process/Utility/RegisterContextFreeBSD_arm.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
#include "Plugins/Process/Utility/UnwindLLDB.h"
#include "ProcessFreeBSD.h"
@@ -137,7 +137,7 @@
reg_interface = new RegisterInfoPOSIX_arm64(target_arch);
break;
case llvm::Triple::arm:
- reg_interface = new RegisterContextFreeBSD_arm(target_arch);
+ reg_interface = new RegisterInfoPOSIX_arm(target_arch);
break;
case llvm::Triple::ppc:
#ifndef __powerpc64__
Index: lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.cpp
===
--- lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.cpp
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.cpp
@@ -0,0 +1,94 @@
+//===-- RegisterInfoPOSIX_arm.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===-===//
+
+#include
+#include
+#include
+
+#include "lldb/lldb-defines.h"
+#include "llvm/Support/Compiler.h"
+
+#include "RegisterInfoPOSIX_arm.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+// Based on RegisterContextDarwin_arm.cpp
+#define GPR_OFFSET(i
[Lldb-commits] [lldb] r296335 - Merge Linux and FreeBSD arm register contexts
Author: labath
Date: Mon Feb 27 07:00:50 2017
New Revision: 296335
URL: http://llvm.org/viewvc/llvm-project?rev=296335&view=rev
Log:
Merge Linux and FreeBSD arm register contexts
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
Added:
lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.cpp
- copied, changed from r296334,
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLinux_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm.h
- copied, changed from r296334,
lldb/trunk/source/Plugins/Process/Utility/RegisterContextFreeBSD_arm.h
Removed:
lldb/trunk/source/Plugins/Process/Utility/RegisterContextFreeBSD_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextFreeBSD_arm.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLinux_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLinux_arm.h
Modified:
lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt
lldb/trunk/source/Plugins/Process/elf-core/ThreadElfCore.cpp
Modified: lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp?rev=296335&r1=296334&r2=296335&view=diff
==
--- lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp (original)
+++ lldb/trunk/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp Mon Feb 27
07:00:50 2017
@@ -18,11 +18,11 @@
// Project includes
#include "FreeBSDThread.h"
#include "POSIXStopInfo.h"
-#include "Plugins/Process/Utility/RegisterContextFreeBSD_arm.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.h"
#include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
#include "Plugins/Process/Utility/UnwindLLDB.h"
#include "ProcessFreeBSD.h"
@@ -137,7 +137,7 @@ lldb::RegisterContextSP FreeBSDThread::G
reg_interface = new RegisterInfoPOSIX_arm64(target_arch);
break;
case llvm::Triple::arm:
- reg_interface = new RegisterContextFreeBSD_arm(target_arch);
+ reg_interface = new RegisterInfoPOSIX_arm(target_arch);
break;
case llvm::Triple::ppc:
#ifndef __powerpc64__
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp?rev=296335&r1=296334&r2=296335&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
(original)
+++ lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
Mon Feb 27 07:00:50 2017
@@ -18,7 +18,7 @@
#include "Plugins/Process/Linux/Procfs.h"
#include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
-#include "Plugins/Process/Utility/RegisterContextLinux_arm.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
#include
#include
@@ -109,7 +109,7 @@ NativeRegisterContextLinux_arm::NativeRe
const ArchSpec &target_arch, NativeThreadProtocol &native_thread,
uint32_t concrete_frame_idx)
: NativeRegisterContextLinux(native_thread, concrete_frame_idx,
- new RegisterContextLinux_arm(target_arch)) {
+ new RegisterInfoPOSIX_arm(target_arch)) {
switch (target_arch.GetMachine()) {
case llvm::Triple::arm:
m_reg_info.num_registers = k_num_registers_arm;
Modified: lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt?rev=296335&r1=296334&r2=296335&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt Mon Feb 27
07:00:50 2017
@@ -15,13 +15,11 @@ add_lldb_library(lldbPluginProcessUtilit
RegisterContextDarwin_i386.cpp
RegisterContextDarwin_x86_64.cpp
RegisterContextDummy.cpp
- RegisterContextFreeBSD_arm.cpp
RegisterContextFreeBSD_i386.cpp
RegisterContextFreeBSD_mips64.cpp
RegisterContextFreeBSD_powerpc.cpp
RegisterContextFreeBSD_x86_64.cpp
RegisterContextHistory.cpp
[Lldb-commits] [PATCH] D30402: Modernize Enable/DisableLogChannel interface a bit
labath created this revision.
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef.
https://reviews.llvm.org/D30402
Files:
include/lldb/Core/Debugger.h
include/lldb/Core/Log.h
include/lldb/Interpreter/Args.h
source/API/SBDebugger.cpp
source/Commands/CommandObjectLog.cpp
source/Core/Debugger.cpp
source/Core/Log.cpp
tools/lldb-server/LLDBServerUtilities.cpp
unittests/Core/LogTest.cpp
unittests/Interpreter/TestArgs.cpp
Index: unittests/Interpreter/TestArgs.cpp
===
--- unittests/Interpreter/TestArgs.cpp
+++ unittests/Interpreter/TestArgs.cpp
@@ -169,6 +169,14 @@
EXPECT_STREQ("4", args.GetArgumentAtIndex(3));
}
+TEST(ArgsTest, GetArgumentArrayRef) {
+ Args args("foo bar");
+ llvm::ArrayRef ref = args.GetArgumentArrayRef();
+ ASSERT_EQ(2u, ref.size());
+ EXPECT_STREQ("foo", ref[0]);
+ EXPECT_STREQ("bar", ref[1]);
+}
+
TEST(ArgsTest, StringToBoolean) {
bool success = false;
EXPECT_TRUE(Args::StringToBoolean(llvm::StringRef("true"), false, nullptr));
Index: unittests/Core/LogTest.cpp
===
--- unittests/Core/LogTest.cpp
+++ unittests/Core/LogTest.cpp
@@ -93,7 +93,7 @@
llvm::llvm_shutdown_obj obj;
Log::Register("chan", test_channel);
EXPECT_EQ(nullptr, test_channel.GetLogIfAny(FOO));
- const char *cat1[] = {"foo", nullptr};
+ const char *cat1[] = {"foo"};
std::string message;
std::shared_ptr stream_sp(
new llvm::raw_string_ostream(message));
@@ -110,20 +110,20 @@
std::shared_ptr stream_sp(
new llvm::raw_string_ostream(message));
StreamString err;
- EXPECT_FALSE(Log::EnableLogChannel(stream_sp, 0, "chanchan", nullptr, err));
+ EXPECT_FALSE(Log::EnableLogChannel(stream_sp, 0, "chanchan", {}, err));
EXPECT_EQ("Invalid log channel 'chanchan'.\n", err.GetString());
err.Clear();
- EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", nullptr, err));
- EXPECT_EQ("", err.GetString());
+ EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", {}, err));
+ EXPECT_EQ("", err.GetString()) << "err: " << err.GetString().str();
EXPECT_NE(nullptr, test_channel.GetLogIfAll(FOO));
EXPECT_EQ(nullptr, test_channel.GetLogIfAll(BAR));
- const char *cat2[] = {"bar", nullptr};
+ const char *cat2[] = {"bar"};
EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", cat2, err));
EXPECT_NE(nullptr, test_channel.GetLogIfAll(FOO | BAR));
- const char *cat3[] = {"baz", nullptr};
+ const char *cat3[] = {"baz"};
EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", cat3, err));
EXPECT_TRUE(err.GetString().contains("unrecognized log category 'baz'"))
<< "err: " << err.GetString().str();
@@ -146,28 +146,28 @@
TEST_F(LogChannelTest, Disable) {
EXPECT_EQ(nullptr, test_channel.GetLogIfAll(FOO));
- const char *cat12[] = {"foo", "bar", nullptr};
+ const char *cat12[] = {"foo", "bar"};
std::string message;
std::shared_ptr stream_sp(
new llvm::raw_string_ostream(message));
StreamString err;
EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", cat12, err));
EXPECT_NE(nullptr, test_channel.GetLogIfAll(FOO | BAR));
- const char *cat2[] = {"bar", nullptr};
+ const char *cat2[] = {"bar"};
EXPECT_TRUE(Log::DisableLogChannel("chan", cat2, err));
EXPECT_NE(nullptr, test_channel.GetLogIfAll(FOO));
EXPECT_EQ(nullptr, test_channel.GetLogIfAll(BAR));
- const char *cat3[] = {"baz", nullptr};
+ const char *cat3[] = {"baz"};
EXPECT_TRUE(Log::DisableLogChannel("chan", cat3, err));
EXPECT_TRUE(err.GetString().contains("unrecognized log category 'baz'"))
<< "err: " << err.GetString().str();
EXPECT_NE(nullptr, test_channel.GetLogIfAll(FOO));
EXPECT_EQ(nullptr, test_channel.GetLogIfAll(BAR));
err.Clear();
- EXPECT_TRUE(Log::DisableLogChannel("chan", nullptr, err));
+ EXPECT_TRUE(Log::DisableLogChannel("chan", {}, err));
EXPECT_EQ(nullptr, test_channel.GetLogIfAny(FOO | BAR));
}
@@ -195,13 +195,13 @@
std::shared_ptr stream_sp(
new llvm::raw_string_ostream(message));
StreamString err;
- EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", nullptr, err));
+ EXPECT_TRUE(Log::EnableLogChannel(stream_sp, 0, "chan", {}, err));
Log *log = test_channel.GetLogIfAll(FOO);
// Start logging on one thread. Concurrently, try disabling the log channel.
std::thread log_thread([log] { LLDB_LOG(log, "Hello World"); });
- EXPECT_TRUE(Log::DisableLogChannel("chan", nullptr, err));
+ EXPECT_TRUE(Log::DisableLogChannel("chan", {}, err));
log_thread.join();
// The log thread either managed to write to the log in time, or it didn't. In
Index: tools/lldb-server/LLDBServerUtilities.cpp
===
--- tools/lldb-server/LLDBServerUtilities.cpp
+++ tools/lldb-server/LLDBServerUtilities.cpp
@@ -52,8 +52,8
[Lldb-commits] [lldb] r296333 - Remove the callback-based log channel registration mechanism
Author: labath
Date: Mon Feb 27 06:21:16 2017
New Revision: 296333
URL: http://llvm.org/viewvc/llvm-project?rev=296333&view=rev
Log:
Remove the callback-based log channel registration mechanism
All the existing channels have beens switched to the new mechanism and
this code is now unused.
Modified:
lldb/trunk/include/lldb/Core/Log.h
lldb/trunk/source/API/SBCommandReturnObject.cpp
lldb/trunk/source/Core/Log.cpp
Modified: lldb/trunk/include/lldb/Core/Log.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Log.h?rev=296333&r1=296332&r2=296333&view=diff
==
--- lldb/trunk/include/lldb/Core/Log.h (original)
+++ lldb/trunk/include/lldb/Core/Log.h Mon Feb 27 06:21:16 2017
@@ -12,7 +12,6 @@
// Project includes
#include "lldb/Core/Logging.h"
-#include "lldb/Utility/ConstString.h"
#include "lldb/Utility/Flags.h"
#include "lldb/lldb-private.h"
@@ -93,35 +92,11 @@ public:
};
//--
- // Callback definitions for abstracted plug-in log access.
- //--
- typedef void (*DisableCallback)(const char **categories,
- Stream *feedback_strm);
- typedef Log *(*EnableCallback)(
- const std::shared_ptr &log_stream_sp,
- uint32_t log_options, const char **categories, Stream *feedback_strm);
- typedef void (*ListCategoriesCallback)(Stream *strm);
-
- struct Callbacks {
-DisableCallback disable;
-EnableCallback enable;
-ListCategoriesCallback list_categories;
- };
-
- //--
// Static accessors for logging channels
//--
static void Register(llvm::StringRef name, Channel &channel);
static void Unregister(llvm::StringRef name);
- static void RegisterLogChannel(const ConstString &channel,
- const Log::Callbacks &log_callbacks);
-
- static bool UnregisterLogChannel(const ConstString &channel);
-
- static bool GetLogChannelCallbacks(const ConstString &channel,
- Log::Callbacks &log_callbacks);
-
static bool
EnableLogChannel(const std::shared_ptr &log_stream_sp,
uint32_t log_options, llvm::StringRef channel,
Modified: lldb/trunk/source/API/SBCommandReturnObject.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCommandReturnObject.cpp?rev=296333&r1=296332&r2=296333&view=diff
==
--- lldb/trunk/source/API/SBCommandReturnObject.cpp (original)
+++ lldb/trunk/source/API/SBCommandReturnObject.cpp Mon Feb 27 06:21:16 2017
@@ -17,6 +17,7 @@
#include "lldb/Core/Log.h"
#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Utility/ConstString.h"
#include "lldb/Utility/Error.h"
using namespace lldb;
Modified: lldb/trunk/source/Core/Log.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Log.cpp?rev=296333&r1=296332&r2=296333&view=diff
==
--- lldb/trunk/source/Core/Log.cpp (original)
+++ lldb/trunk/source/Core/Log.cpp Mon Feb 27 06:21:16 2017
@@ -222,16 +222,6 @@ void Log::Warning(const char *format, ..
free(arg_msg);
}
-typedef std::map CallbackMap;
-typedef CallbackMap::iterator CallbackMapIter;
-
-// Surround our callback map with a singleton function so we don't have any
-// global initializers.
-static CallbackMap &GetCallbackMap() {
- static CallbackMap g_callback_map;
- return g_callback_map;
-}
-
void Log::Register(llvm::StringRef name, Channel &channel) {
auto iter = g_channel_map->try_emplace(name, channel);
assert(iter.second == true);
@@ -245,37 +235,10 @@ void Log::Unregister(llvm::StringRef nam
g_channel_map->erase(iter);
}
-void Log::RegisterLogChannel(const ConstString &channel,
- const Log::Callbacks &log_callbacks) {
- GetCallbackMap().insert(std::make_pair(channel, log_callbacks));
-}
-
-bool Log::UnregisterLogChannel(const ConstString &channel) {
- return GetCallbackMap().erase(channel) != 0;
-}
-
-bool Log::GetLogChannelCallbacks(const ConstString &channel,
- Log::Callbacks &log_callbacks) {
- CallbackMap &callback_map = GetCallbackMap();
- CallbackMapIter pos = callback_map.find(channel);
- if (pos != callback_map.end()) {
-log_callbacks = pos->second;
-return true;
- }
- ::memset(&log_callbacks, 0, sizeof(log_callbacks));
- return false;
-}
-
bool Log::EnableLogChannel(
const std::shared_ptr &log_stream_sp,
uint32_t log_options, llvm::StringRef channel, const char **categories,
Stream &error_stream) {
- Log::Callbacks log_callbacks;
- if (Log::GetLogChannelCallbacks(Co
[Lldb-commits] [lldb] r296334 - Fix MinidumpParserTest on 32-bit arches
Author: labath
Date: Mon Feb 27 06:21:20 2017
New Revision: 296334
URL: http://llvm.org/viewvc/llvm-project?rev=296334&view=rev
Log:
Fix MinidumpParserTest on 32-bit arches
load_size should be 64-bit unconditionally to match the underlying API.
This makes sure the MAX value correctly signals to auto-detect the file
size when mmap()ing.
Modified:
lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
Modified: lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp?rev=296334&r1=296333&r2=296334&view=diff
==
--- lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp (original)
+++ lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp Mon Feb 27
06:21:20 2017
@@ -48,7 +48,8 @@ public:
llvm::sys::path::append(inputs_folder, "Inputs");
}
- void SetUpData(const char *minidump_filename, size_t load_size = SIZE_MAX) {
+ void SetUpData(const char *minidump_filename,
+ uint64_t load_size = UINT64_MAX) {
llvm::SmallString<128> filename = inputs_folder;
llvm::sys::path::append(filename, minidump_filename);
@@ -452,4 +453,4 @@ TEST_F(MinidumpParserTest, ConvertMinidu
REG_VAL32(buf->GetBytes() + reg_info[reg_index].byte_offset));
}
}
-}
\ No newline at end of file
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D30249: Clear expression when breakpoint location becomes unresolved
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296328: Switch SBBreakpoint to storing a weak_ptr of the
internal breakpoint object (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D30249?vs=89645&id=89858#toc
Repository:
rL LLVM
https://reviews.llvm.org/D30249
Files:
lldb/trunk/include/lldb/API/SBBreakpoint.h
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
lldb/trunk/source/API/SBBreakpoint.cpp
lldb/trunk/source/API/SBBreakpointLocation.cpp
lldb/trunk/source/API/SBTarget.cpp
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
@@ -52,7 +52,6 @@
self.thread = lldbutil.get_one_thread_stopped_at_breakpoint(self.process, self.breakpoint1)
self.assertIsNotNone(self.thread, "Didn't stop at breakpoint 1.")
-@skipIf(bugnumber="llvm.org/pr31972", hostoslist=["windows"])
def test_step_instruction(self):
# Count instructions between breakpoint_1 and breakpoint_4
contextList = self.target.FindFunctions('main', lldb.eFunctionNameTypeAuto)
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
@@ -17,6 +17,7 @@
class BreakpointAPITestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
@add_test_categories(['pyapi'])
def test_breakpoint_is_valid(self):
@@ -49,3 +50,25 @@
self.assertTrue(
not breakpoint,
"Breakpoint we deleted is no longer valid.")
+
+@add_test_categories(['pyapi'])
+def test_target_delete(self):
+"""Make sure that if an SBTarget gets deleted the associated
+Breakpoint's IsValid returns false."""
+
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+# Now create a breakpoint on main.c by name 'AFunction'.
+breakpoint = target.BreakpointCreateByName('AFunction', 'a.out')
+#print("breakpoint:", breakpoint)
+self.assertTrue(breakpoint and
+breakpoint.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+
+self.assertTrue(self.dbg.DeleteTarget(target))
+self.assertFalse(breakpoint.IsValid())
Index: lldb/trunk/source/API/SBTarget.cpp
===
--- lldb/trunk/source/API/SBTarget.cpp
+++ lldb/trunk/source/API/SBTarget.cpp
@@ -686,7 +686,7 @@
if (sb_module_list.GetSize() > 0) {
module_list = sb_module_list.get();
}
-*sb_bp = target_sp->CreateBreakpoint(
+sb_bp = target_sp->CreateBreakpoint(
module_list, *sb_file_spec, line, offset, check_inlines, skip_prologue,
internal, hardware, move_to_nearest_code);
}
@@ -699,7 +699,7 @@
log->Printf("SBTarget(%p)::BreakpointCreateByLocation ( %s:%u ) => "
"SBBreakpoint(%p): %s",
static_cast(target_sp.get()), path, line,
-static_cast(sb_bp.get()), sstr.GetData());
+static_cast(sb_bp.GetSP().get()), sstr.GetData());
}
return sb_bp;
@@ -721,11 +721,11 @@
if (module_name && module_name[0]) {
FileSpecList module_spec_list;
module_spec_list.Append(FileSpec(module_name, false));
- *sb_bp = target_sp->CreateBreakpoint(
+ sb_bp = target_sp->CreateBreakpoint(
&module_spec_list, NULL, symbol_name, eFunctionNameTypeAuto,
eLanguageTypeUnknown, offset, skip_prologue, internal, hardware);
} else {
- *sb_bp = target_sp->CreateBreakpoint(
+ sb_bp = target_sp->CreateBreakpoint(
NULL, NULL, symbol_name, eFunctionNameTypeAuto, eLanguageTypeUnknown,
offset, skip_prologue, internal, hardware);
}
@@ -735,7 +735,7 @@
log->Printf("SBTarget(%p)::BreakpointCreateByName (symbol=\"%s\", "
"module=\"%s\") => SBBreakpoint(%p)",
static_cast(target_sp.get()), symbol_name, module_name,
-static_cast(sb_bp.get()));
+static_cast(sb_bp.GetSP().get()));
return sb_bp;
}
@@
[Lldb-commits] [lldb] r296329 - Log: Fix a regression in handling log options
Author: labath
Date: Mon Feb 27 05:05:39 2017
New Revision: 296329
URL: http://llvm.org/viewvc/llvm-project?rev=296329&view=rev
Log:
Log: Fix a regression in handling log options
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the channel. Fix that and add a
test.
Modified:
lldb/trunk/include/lldb/Core/Log.h
lldb/trunk/source/Core/Log.cpp
lldb/trunk/unittests/Core/LogTest.cpp
Modified: lldb/trunk/include/lldb/Core/Log.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Log.h?rev=296329&r1=296328&r2=296329&view=diff
==
--- lldb/trunk/include/lldb/Core/Log.h (original)
+++ lldb/trunk/include/lldb/Core/Log.h Mon Feb 27 05:05:39 2017
@@ -86,7 +86,7 @@ public:
// Calls to Enable and disable need to be serialized externally.
void Enable(Log &log, const std::shared_ptr &stream_sp,
-uint32_t flags);
+uint32_t options, uint32_t flags);
// Calls to Enable and disable need to be serialized externally.
void Disable(uint32_t flags);
Modified: lldb/trunk/source/Core/Log.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Log.cpp?rev=296329&r1=296328&r2=296329&view=diff
==
--- lldb/trunk/source/Core/Log.cpp (original)
+++ lldb/trunk/source/Core/Log.cpp Mon Feb 27 05:05:39 2017
@@ -89,9 +89,10 @@ static uint32_t GetFlags(Stream &stream,
void Log::Channel::Enable(Log &log,
const std::shared_ptr &stream_sp,
- uint32_t flags) {
+ uint32_t options, uint32_t flags) {
log.GetMask().Set(flags);
if (log.GetMask().Get()) {
+log.GetOptions().Set(options);
log.SetStream(stream_sp);
log_ptr.store(&log, std::memory_order_release);
}
@@ -283,7 +284,8 @@ bool Log::EnableLogChannel(
uint32_t flags = categories && categories[0]
? GetFlags(error_stream, *iter, categories)
: iter->second.channel.default_flags;
- iter->second.channel.Enable(iter->second.log, log_stream_sp, flags);
+ iter->second.channel.Enable(iter->second.log, log_stream_sp, log_options,
+ flags);
return true;
}
Modified: lldb/trunk/unittests/Core/LogTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Core/LogTest.cpp?rev=296329&r1=296328&r2=296329&view=diff
==
--- lldb/trunk/unittests/Core/LogTest.cpp (original)
+++ lldb/trunk/unittests/Core/LogTest.cpp Mon Feb 27 05:05:39 2017
@@ -130,6 +130,20 @@ TEST_F(LogChannelTest, Enable) {
EXPECT_NE(nullptr, test_channel.GetLogIfAll(FOO | BAR));
}
+TEST_F(LogChannelTest, EnableOptions) {
+ EXPECT_EQ(nullptr, test_channel.GetLogIfAll(FOO));
+ std::string message;
+ std::shared_ptr stream_sp(
+ new llvm::raw_string_ostream(message));
+ StreamString err;
+ EXPECT_TRUE(Log::EnableLogChannel(stream_sp, LLDB_LOG_OPTION_VERBOSE, "chan",
+nullptr, err));
+
+ Log *log = test_channel.GetLogIfAll(FOO);
+ ASSERT_NE(nullptr, log);
+ EXPECT_TRUE(log->GetVerbose());
+}
+
TEST_F(LogChannelTest, Disable) {
EXPECT_EQ(nullptr, test_channel.GetLogIfAll(FOO));
const char *cat12[] = {"foo", "bar", nullptr};
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r296328 - Switch SBBreakpoint to storing a weak_ptr of the internal breakpoint object
Author: labath
Date: Mon Feb 27 05:05:34 2017
New Revision: 296328
URL: http://llvm.org/viewvc/llvm-project?rev=296328&view=rev
Log:
Switch SBBreakpoint to storing a weak_ptr of the internal breakpoint object
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
Modified:
lldb/trunk/include/lldb/API/SBBreakpoint.h
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
lldb/trunk/source/API/SBBreakpoint.cpp
lldb/trunk/source/API/SBBreakpointLocation.cpp
lldb/trunk/source/API/SBTarget.cpp
Modified: lldb/trunk/include/lldb/API/SBBreakpoint.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBBreakpoint.h?rev=296328&r1=296327&r2=296328&view=diff
==
--- lldb/trunk/include/lldb/API/SBBreakpoint.h (original)
+++ lldb/trunk/include/lldb/API/SBBreakpoint.h Mon Feb 27 05:05:34 2017
@@ -133,19 +133,13 @@ private:
SBBreakpoint(const lldb::BreakpointSP &bp_sp);
- lldb_private::Breakpoint *operator->() const;
-
- lldb_private::Breakpoint *get() const;
-
- lldb::BreakpointSP &operator*();
-
- const lldb::BreakpointSP &operator*() const;
-
static bool PrivateBreakpointHitCallback(
void *baton, lldb_private::StoppointCallbackContext *context,
lldb::user_id_t break_id, lldb::user_id_t break_loc_id);
- lldb::BreakpointSP m_opaque_sp;
+ lldb::BreakpointSP GetSP() const;
+
+ lldb::BreakpointWP m_opaque_wp;
};
class LLDB_API SBBreakpointList {
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py?rev=296328&r1=296327&r2=296328&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
Mon Feb 27 05:05:34 2017
@@ -52,7 +52,6 @@ class StepOverBreakpointsTestCase(TestBa
self.thread =
lldbutil.get_one_thread_stopped_at_breakpoint(self.process, self.breakpoint1)
self.assertIsNotNone(self.thread, "Didn't stop at breakpoint 1.")
-@skipIf(bugnumber="llvm.org/pr31972", hostoslist=["windows"])
def test_step_instruction(self):
# Count instructions between breakpoint_1 and breakpoint_4
contextList = self.target.FindFunctions('main',
lldb.eFunctionNameTypeAuto)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py?rev=296328&r1=296327&r2=296328&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/breakpoint/TestBreakpointAPI.py
Mon Feb 27 05:05:34 2017
@@ -17,6 +17,7 @@ from lldbsuite.test import lldbutil
class BreakpointAPITestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
@add_test_categories(['pyapi'])
def test_breakpoint_is_valid(self):
@@ -49,3 +50,25 @@ class BreakpointAPITestCase(TestBase):
self.assertTrue(
not breakpoint,
"Breakpoint we deleted is no longer valid.")
+
+@add_test_categories(['pyapi'])
+def test_target_delete(self):
+"""Make sure that if an SBTarget gets deleted the associated
+Breakpoint's IsValid returns false."""
+
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+# Now create a breakpoint on main.c by name 'AFunction'.
+breakpoint = target.BreakpointCreateByName('AFunction', 'a.out')
+#print("breakpoint:", breakpoint)
+self.assertTrue(breakpoint and
+breakpoint.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+
+self.assertTrue(self.db
[Lldb-commits] [PATCH] D30249: Clear expression when breakpoint location becomes unresolved
labath added a comment. I like `bkpt_sp`. I will rename it before submission. It does not make the diff any larger as I have had to rename all occurrences of it anyway. https://reviews.llvm.org/D30249 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D30054: Delete DataBufferMemoryMap
I was thinking of a simple test like "call get on an existing file and make sure it returns something reasonable" and "call get on a non-existing file and make sure it returns null". This is a very thin wrapper over over the llvm code, so I don't insist on it though... On 24 February 2017 at 15:18, Zachary Turner wrote: > I left out unit tests since we'd essentially be duplicating the unit tests > of MemoryBuffer, and because it involves the file system (also this is > temporary code until DataBuffer stuff goes away). Lmk if you disagree though > On Fri, Feb 24, 2017 at 2:53 AM Pavel Labath via Phabricator > wrote: >> >> labath added a comment. >> >> I am not sure if this is a voting situation, but I agree with what Zachary >> said above. >> >> Since we're already speaking about tests, it looks like the new >> DataBufferLLVM class could use a unit test or two, just so we get in the >> habit of writing those. >> >> >> https://reviews.llvm.org/D30054 >> >> >> > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
