[Lldb-commits] [PATCH] D43059: Add implementation for MSVC in CPlusPlusLanguage::IsCPPMangledName
labath requested changes to this revision. labath added a comment. This revision now requires changes to proceed. That seems extremely dodgy. Surely whether something is a mangled name does not depend on the compiler we built lldb with. I am aware that we have many places with _Z hardcoded, but this seems to be making the situation only worse. I'm not sure how is this API being used, but maybe this should just recognize both mangling schemes unconditionally ? Repository: rL LLVM https://reviews.llvm.org/D43059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42994: Stop passing -fPIC to lldb tests on Windows
labath added inline comments. Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:550 #-- $(DYLIB_OBJECTS) : CFLAGS += -DCOMPILING_LLDB_TEST_DLL I think Zachary meant only when building the shared library, but you're doing it unconditionally. This would be a nice place to set the flag for shared library only. https://reviews.llvm.org/D42994 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r324590 - Rewrite the flaky test_restart_bug test in a more deterministic way
Author: labath
Date: Thu Feb 8 02:37:23 2018
New Revision: 324590
URL: http://llvm.org/viewvc/llvm-project?rev=324590&view=rev
Log:
Rewrite the flaky test_restart_bug test in a more deterministic way
Summary:
The test was trying to reproduce a bug in handling of two concurrent
events, which was impossible to do reliably in a black-box style test.
In practice, this meant the test was only ever failing on remote
targets, as these were slow enough to trigger this.
Fortunately, we now have the ability to mock the server side of the
connection, which means we can simulate the failure deterministically,
so I rewrite the test to use the new gdb-client framework.
I've needed to add a couple of new packets to the mock server to be able
to do this. Instead of trying to guess how a "typical" gdb-client test
will want to handle this, I throw an exception in the implementation to
force the user to override them (the packets are only sent if the test
explicitly performs some action which will trigger them, so a basic test
which e.g. does not need the "continue" functionality will not need to
implement them).
Reviewers: owenpshaw
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D42959
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/signal/raise/TestRaise.py
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py?rev=324590&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py
Thu Feb 8 02:37:23 2018
@@ -0,0 +1,62 @@
+from __future__ import print_function
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from gdbclientutils import *
+
+
+class TestRestartBug(GDBRemoteTestBase):
+
+@expectedFailureAll(bugnumber="llvm.org/pr24530")
+def test(self):
+"""
+Test auto-continue behavior when a process is interrupted to deliver
+an "asynchronous" packet. This simulates the situation when a process
+stops on its own just as lldb client is about to interrupt it. The
+client should not auto-continue in this case, unless the user has
+explicitly requested that we ignore signals of this type.
+"""
+class MyResponder(MockGDBServerResponder):
+continueCount = 0
+
+def setBreakpoint(self, packet):
+return "OK"
+
+def interrupt(self):
+# Simulate process stopping due to a raise(SIGINT) just as lldb
+# is about to interrupt it.
+return "T02reason:signal"
+
+def cont(self):
+self.continueCount += 1
+if self.continueCount == 1:
+# No response, wait for the client to interrupt us.
+return None
+return "W00" # Exit
+
+self.server.responder = MyResponder()
+target = self.createTarget("a.yaml")
+process = self.connect(target)
+self.dbg.SetAsync(True)
+process.Continue()
+
+# resume the process and immediately try to set another breakpoint.
When using the remote
+# stub, this will trigger a request to stop the process. Make sure we
+# do not lose this signal.
+bkpt = target.BreakpointCreateByAddress(0x1234)
+self.assertTrue(bkpt.IsValid())
+self.assertEqual(bkpt.GetNumLocations(), 1)
+
+event = lldb.SBEvent()
+while self.dbg.GetListener().WaitForEvent(2, event):
+if self.TraceOn():
+print("Process changing state to:",
+self.dbg.StateAsCString(process.GetStateFromEvent(event)))
+if process.GetStateFromEvent(event) == lldb.eStateExited:
+break
+
+# We should get only one continue packet as the client should not
+# auto-continue after setting the breakpoint.
+self.assertEqual(self.server.responder.continueCount, 1)
+# And the process should end up in the stopped state.
+self.assertEqual(process.GetState(), lldb.eStateStopped)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py?rev=324590&r1=324589&r2=324590&view=diff
[Lldb-commits] [PATCH] D42959: Rewrite the flaky test_restart_bug test in a more deterministic way
This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rL324590: Rewrite the flaky test_restart_bug test in a more deterministic way (authored by labath, committed by ). Herald added a subscriber: llvm-commits. Repository: rL LLVM https://reviews.llvm.org/D42959 Files: lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/signal/raise/TestRaise.py Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py === --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py @@ -98,6 +98,10 @@ to the given packet received from the client. """ self.packetLog.append(packet) +if packet is MockGDBServer.PACKET_INTERRUPT: +return self.interrupt() +if packet == "c": +return self.cont() if packet == "g": return self.readRegisters() if packet[0] == "G": @@ -133,8 +137,16 @@ if data is not None: return self._qXferResponse(data, has_more) return "" +if packet[0] == "Z": +return self.setBreakpoint(packet) return self.other(packet) +def interrupt(self): +raise self.UnexpectedPacketException() + +def cont(self): +raise self.UnexpectedPacketException() + def readRegisters(self): return "" * self.registerCount @@ -178,10 +190,21 @@ def selectThread(self, op, thread_id): return "OK" +def setBreakpoint(self, packet): +raise self.UnexpectedPacketException() + def other(self, packet): # empty string means unsupported return "" +""" +Raised when we receive a packet for which there is no default action. +Override the responder class to implement behavior suitable for the test at +hand. +""" +class UnexpectedPacketException(Exception): +pass + class MockGDBServer: """ @@ -288,6 +311,9 @@ if data[0] == '+': self._receivedData = data[1:] return self.PACKET_ACK +if ord(data[0]) == 3: +self._receivedData = data[1:] +return self.PACKET_INTERRUPT if data[0] == '$': i += 1 else: @@ -343,10 +369,12 @@ # Delegate everything else to our responder response = self.responder.respond(packet) # Handle packet framing since we don't want to bother tests with it. -framed = frame_packet(response) -self._client.sendall(framed) +if response is not None: +framed = frame_packet(response) +self._client.sendall(framed) PACKET_ACK = object() +PACKET_INTERRUPT = object() class InvalidPacketException(Exception): pass @@ -410,6 +438,7 @@ process = target.ConnectRemote(listener, url, "gdb-remote", error) self.assertTrue(error.Success(), error.description) self.assertTrue(process, PROCESS_IS_VALID) +return process def assertPacketLogContains(self, packets): """ Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py === --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestRestartBug.py @@ -0,0 +1,62 @@ +from __future__ import print_function +import lldb +from lldbsuite.test.lldbtest import * +from lldbsuite.test.decorators import * +from gdbclientutils import * + + +class TestRestartBug(GDBRemoteTestBase): + +@expectedFailureAll(bugnumber="llvm.org/pr24530") +def test(self): +""" +Test auto-continue behavior when a process is interrupted to deliver +an "asynchronous" packet. This simulates the situation when a process +stops on its own just as lldb client is about to interrupt it. The +client should not auto-continue in this case, unless the user has +explicitly requested that we ignore signals of this type. +""" +class MyResponder(MockGDBServerResponder): +continueCount = 0 + +def setBreakpoint(self, packet): +return "OK" + +def interrupt(self): +# Simulate process stopping due to a raise(SIGINT) just as lldb +# is about to
[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
labath added a comment. The change seems fine to me, and I don't really have anything to add to the things that were said already. Testing the completion of things that require a target/module/etc. will be a bit tricky, but that's something we should figure out anyway to have more targeted completion tests. https://reviews.llvm.org/D43048 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43076: llgs-test: Parse and store register info recieved from lldb-server
labath created this revision.
labath added reviewers: eugene, davide.
Right now the test client is not parsing register values correctly,
which is manifesting itself in one test failing on 32-bit architectures
(pr36013). This parses the information from the qRegisterInfo packets
and stores it in the client, which will enable fixing the parsing in a
follow up commit.
I am also adding a new templated SendMessage overload, which enables one
to send a message get a parsed response in a single call.
https://reviews.llvm.org/D43076
Files:
unittests/tools/lldb-server/tests/MessageObjects.cpp
unittests/tools/lldb-server/tests/MessageObjects.h
unittests/tools/lldb-server/tests/TestClient.cpp
unittests/tools/lldb-server/tests/TestClient.h
unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
Index: unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
===
--- unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
+++ unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
@@ -44,7 +44,7 @@
<< "Thread ID: " << tid << " not in JThreadsInfo.";
auto pc_value = thread_infos[tid].ReadRegisterAsUint64(pc_reg);
ASSERT_THAT_EXPECTED(pc_value, Succeeded());
-ASSERT_EQ(stop_reply_pcs[tid], *pc_value)
+ASSERT_EQ(stop_reply_pc.second, *pc_value)
<< "Mismatched PC for thread: " << tid;
}
}
Index: unittests/tools/lldb-server/tests/TestClient.h
===
--- unittests/tools/lldb-server/tests/TestClient.h
+++ unittests/tools/lldb-server/tests/TestClient.h
@@ -74,23 +74,38 @@
std::string &response_string);
llvm::Error SendMessage(llvm::StringRef message, std::string &response_string,
PacketResult expected_result);
+
+ template
+ llvm::Expected SendMessage(llvm::StringRef Message);
unsigned int GetPcRegisterId();
private:
TestClient(std::unique_ptr Conn);
- llvm::Error QueryProcessInfo();
+ llvm::Error qProcessInfo();
+ llvm::Error qRegisterInfos();
+ llvm::Error queryProcess();
llvm::Error Continue(llvm::StringRef message);
std::string FormatFailedResult(
const std::string &message,
lldb_private::process_gdb_remote::GDBRemoteCommunication::PacketResult
result);
llvm::Optional m_process_info;
std::unique_ptr m_stop_reply;
- unsigned int m_pc_register = UINT_MAX;
+ std::vector m_register_infos;
+ unsigned int m_pc_register = LLDB_INVALID_REGNUM;
};
+template
+llvm::Expected
+TestClient::SendMessage(llvm::StringRef Message) {
+ std::string ResponseText;
+ if (llvm::Error E = SendMessage(Message, ResponseText))
+return std::move(E);
+ return P::create(ResponseText);
+}
+
} // namespace llgs_tests
#endif // LLDB_SERVER_TESTS_TESTCLIENT_H
Index: unittests/tools/lldb-server/tests/TestClient.cpp
===
--- unittests/tools/lldb-server/tests/TestClient.cpp
+++ unittests/tools/lldb-server/tests/TestClient.cpp
@@ -25,8 +25,7 @@
using namespace lldb;
using namespace lldb_private;
using namespace llvm;
-
-namespace llgs_tests {
+using namespace llgs_tests;
TestClient::TestClient(std::unique_ptr Conn) {
SetConnection(Conn.release());
@@ -103,7 +102,7 @@
auto Client = std::unique_ptr(new TestClient(std::move(Conn)));
if (!InferiorArgs.empty()) {
-if (Error E = Client->QueryProcessInfo())
+if (Error E = Client->queryProcess())
return std::move(E);
}
@@ -128,7 +127,7 @@
return E;
if (Error E = SendMessage("qLaunchSuccess"))
return E;
- if (Error E = QueryProcessInfo())
+ if (Error E = queryProcess())
return E;
return Error::success();
}
@@ -147,7 +146,9 @@
return Continue(formatv("vCont;c:{0:x-}", thread_id).str());
}
-const ProcessInfo &TestClient::GetProcessInfo() { return *m_process_info; }
+const llgs_tests::ProcessInfo &TestClient::GetProcessInfo() {
+ return *m_process_info;
+}
Optional TestClient::GetJThreadsInfo() {
std::string response;
@@ -201,42 +202,42 @@
}
unsigned int TestClient::GetPcRegisterId() {
- if (m_pc_register != UINT_MAX)
-return m_pc_register;
-
- for (unsigned int register_id = 0;; register_id++) {
-std::string message = formatv("qRegisterInfo{0:x-}", register_id).str();
-std::string response;
-if (SendMessage(message, response)) {
- GTEST_LOG_(ERROR) << "Unable to query register ID for PC register.";
- return UINT_MAX;
-}
+ assert(m_pc_register != LLDB_INVALID_REGNUM);
+ return m_pc_register;
+}
-auto elements_or_error = SplitUniquePairList("GetPcRegisterId", response);
-if (auto split_error = elements_or_error.takeError()) {
- GTEST_LOG_(ERROR) << "GetPcRegisterId: Error splitting response: "
-<< response;
- return UINT_MAX;
-}
+Error TestClient::qProcessInfo() {
+ m_pr
[Lldb-commits] [PATCH] D42994: Stop passing -fPIC to lldb tests on Windows
asmith updated this revision to Diff 133467.
Repository:
rL LLVM
https://reviews.llvm.org/D42994
Files:
packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/Makefile
packages/Python/lldbsuite/test/functionalities/load_unload/a.mk
packages/Python/lldbsuite/test/functionalities/load_unload/b.mk
packages/Python/lldbsuite/test/functionalities/load_unload/c.mk
packages/Python/lldbsuite/test/functionalities/load_unload/d.mk
packages/Python/lldbsuite/test/functionalities/load_unload/hidden/Makefile
packages/Python/lldbsuite/test/functionalities/pre_run_dylibs/Makefile
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
packages/Python/lldbsuite/test/lang/c/conflicting-symbol/One.mk
packages/Python/lldbsuite/test/lang/c/conflicting-symbol/Two.mk
packages/Python/lldbsuite/test/lang/c/shared_lib/Makefile
packages/Python/lldbsuite/test/lang/c/shared_lib_stripped_symbols/Makefile
packages/Python/lldbsuite/test/lang/c/tls_globals/Makefile
packages/Python/lldbsuite/test/lang/cpp/namespace_definitions/a.mk
packages/Python/lldbsuite/test/lang/cpp/namespace_definitions/b.mk
packages/Python/lldbsuite/test/lldbtest.py
packages/Python/lldbsuite/test/make/Makefile.rules
packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
Index: packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
===
--- packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
+++ packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
@@ -17,19 +17,19 @@
def test_read_memory_c_string(self):
"""Test corner case behavior of SBProcess::ReadCStringFromMemory"""
self.build()
- self.dbg.SetAsync(False)
+self.dbg.SetAsync(False)
self.main_source = "main.c"
self.main_source_path = os.path.join(self.getSourceDir(),
self.main_source)
- self.main_source_spec = lldb.SBFileSpec(self.main_source_path)
- self.exe = self.getBuildArtifact("read-mem-cstring")
+self.main_source_spec = lldb.SBFileSpec(self.main_source_path)
+self.exe = self.getBuildArtifact("read-mem-cstring")
(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
self, 'breakpoint here', self.main_source_spec, None, self.exe)
- frame = thread.GetFrameAtIndex(0)
-
+frame = thread.GetFrameAtIndex(0)
+
err = lldb.SBError()
empty_str_addr = frame.FindVariable("empty_string").GetValueAsUnsigned(err)
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -544,6 +544,11 @@
#--
$(DYLIB_OBJECTS) : CFLAGS += -DCOMPILING_LLDB_TEST_DLL
+ifneq "$(OS)" "Windows_NT"
+$(DYLIB_OBJECTS) : CFLAGS += -fPIC
+$(DYLIB_OBJECTS) : CXXFLAGS += -fPIC
+endif
+
$(DYLIB_FILENAME) : $(DYLIB_OBJECTS)
ifeq "$(OS)" "Darwin"
$(LD) $(DYLIB_OBJECTS) $(LDFLAGS) -install_name "$(DYLIB_EXECUTABLE_PATH)/$(DYLIB_FILENAME)" -dynamiclib -o "$(DYLIB_FILENAME)"
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -1478,10 +1478,10 @@
d = {
'DYLIB_CXX_SOURCES': sources,
'DYLIB_NAME': lib_name,
-'CFLAGS_EXTRAS': "%s -I%s -fPIC" % (stdflag,
-os.path.join(
-os.environ["LLDB_SRC"],
-"include")),
+'CFLAGS_EXTRAS': "%s -I%s " % (stdflag,
+ os.path.join(
+ os.environ["LLDB_SRC"],
+ "include")),
'LD_EXTRAS': "-shared -l%s\liblldb.lib" % self.os.environ["LLDB_IMPLIB_DIR"]}
if self.TraceOn():
print(
Index: packages/Python/lldbsuite/test/lang/cpp/namespace_definitions/b.mk
===
--- packages/Python/lldbsuite/test/lang/cpp/namespace_definitions/b.mk
+++ packages/Python/lldbsuite/test/lang/cpp/namespace_definitions/b.mk
@@ -4,6 +4,4 @@
DYLIB_CXX_SOURCES := b.cpp
DYLIB_ONLY := YES
-CXXFLAGS += -fPIC
-
include $(LEVEL)/Makefile.rules
Index: packages/Python/lldbsuite/test/lang/cpp/namespace_definitions/a.mk
===
[Lldb-commits] [PATCH] D43059: Add implementation for MSVC in CPlusPlusLanguage::IsCPPMangledName
asmith added a comment.
IsCPPMangledName() is a public method to determine if a symbol has a mangled
name.
This change is needed so that lldb can find symbols with MSVC style mangled
names.
Open to suggestions on a better way to deal with this...
Here are all the places it is used:
source/Core/Module.cpp:if (CPlusPlusLanguage::IsCPPMangledName(name_cstr))
source/Core/Module.cpp:
!CPlusPlusLanguage::IsCPPMangledName(name_cstr)) {
source/Core/Mangled.cpp: if
(CPlusPlusLanguage::IsCPPMangledName(mangled_name))
source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:
!CPlusPlusLanguage::IsCPPMangledName(name)) ||
source/Expression/IRExecutionUnit.cpp:if
(CPlusPlusLanguage::IsCPPMangledName(name.GetCString())) {
source/Expression/IRExecutionUnit.cpp:if
(CPlusPlusLanguage::IsCPPMangledName(name.GetCString())) {
Repository:
rL LLVM
https://reviews.llvm.org/D43059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43059: Add implementation for MSVC in CPlusPlusLanguage::IsCPPMangledName
I think just remove the preprocessor block. Imagine debugging a Windows
target from a linux host. This function would return false as written
because the host wasn’t Windows
On Thu, Feb 8, 2018 at 12:18 PM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> asmith added a comment.
>
> IsCPPMangledName() is a public method to determine if a symbol has a
> mangled name.
>
> This change is needed so that lldb can find symbols with MSVC style
> mangled names.
>
> Open to suggestions on a better way to deal with this...
>
> Here are all the places it is used:
>
> source/Core/Module.cpp:if
> (CPlusPlusLanguage::IsCPPMangledName(name_cstr))
> source/Core/Module.cpp:
> !CPlusPlusLanguage::IsCPPMangledName(name_cstr)) {
> source/Core/Mangled.cpp: if
> (CPlusPlusLanguage::IsCPPMangledName(mangled_name))
> source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:
> !CPlusPlusLanguage::IsCPPMangledName(name)) ||
> source/Expression/IRExecutionUnit.cpp:if
> (CPlusPlusLanguage::IsCPPMangledName(name.GetCString())) {
> source/Expression/IRExecutionUnit.cpp:if
> (CPlusPlusLanguage::IsCPPMangledName(name.GetCString())) {
>
>
> Repository:
> rL LLVM
>
> https://reviews.llvm.org/D43059
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43059: Add implementation for MSVC in CPlusPlusLanguage::IsCPPMangledName
asmith added a comment. How about this? if (name == nullptr) return false; return ( (name[0] == '?') || (name[0] == '_' && name[1] == 'Z') ); Repository: rL LLVM https://reviews.llvm.org/D43059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43059: Add implementation for MSVC in CPlusPlusLanguage::IsCPPMangledName
Looks good (but for the _Z case, make sure its length is at least 2) On Thu, Feb 8, 2018 at 12:33 PM Aaron Smith via Phabricator < revi...@reviews.llvm.org> wrote: > asmith added a comment. > > How about this? > > if (name == nullptr) > return false; > > return ( (name[0] == '?') || (name[0] == '_' && name[1] == 'Z') ); > > > Repository: > rL LLVM > > https://reviews.llvm.org/D43059 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r324655 - Rewrite testcase to not depend on Foundation implementation details.
Author: adrian
Date: Thu Feb 8 13:52:28 2018
New Revision: 324655
URL: http://llvm.org/viewvc/llvm-project?rev=324655&view=rev
Log:
Rewrite testcase to not depend on Foundation implementation details.
TODO: Add a separate testcase testing *only* Foundation implementation details!
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/minmax.h
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/main.m
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/module.map
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/myModule.h
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/myModule.m
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile?rev=324655&r1=324654&r2=324655&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
Thu Feb 8 13:52:28 2018
@@ -4,5 +4,5 @@ OBJC_SOURCES := main.m myModule.m
include $(LEVEL)/Makefile.rules
-CFLAGS += $(MANDATORY_MODULE_BUILD_CFLAGS) -I$(PWD)
+CFLAGS += $(MANDATORY_MODULE_BUILD_CFLAGS)
LDFLAGS += -framework Foundation
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py?rev=324655&r1=324654&r2=324655&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
Thu Feb 8 13:52:28 2018
@@ -22,15 +22,12 @@ class IncompleteModulesTestCase(TestBase
# Find the line number to break inside main().
self.line = line_number('main.m', '// Set breakpoint 0 here.')
-@skipIfDarwin
@skipUnlessDarwin
-@skipIf(macos_version=["<", "10.12"], debug_info=no_match(["gmodules"]))
+@skipIf(debug_info=no_match(["gmodules"]))
def test_expr(self):
self.build()
exe = self.getBuildArtifact("a.out")
self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
-
-# Break inside the foo function which takes a bar_ptr argument.
lldbutil.run_break_set_by_file_and_line(
self, "main.m", self.line, num_expected_locations=1,
loc_exact=True)
@@ -54,14 +51,14 @@ class IncompleteModulesTestCase(TestBase
substrs=["int", "3"])
self.expect(
-"expr [myObject privateMethod]",
+"expr private_func()",
VARIABLES_DISPLAYED_CORRECTLY,
substrs=[
"int",
"5"])
-self.expect("expr MIN(2,3)", "#defined macro was found",
+self.expect("expr MY_MIN(2,3)", "#defined macro was found",
substrs=["int", "2"])
-self.expect("expr MAX(2,3)", "#undefd macro was correcltly not found",
+self.expect("expr MY_MAX(2,3)", "#undefd macro was correctly not
found",
error=True)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/main.m
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/main.m?rev=324655&r1=324654&r2=324655&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/main.m
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/main.m
Thu Feb 8 13:52:28 2018
@@ -1,11 +1,7 @@
-@import Foundation;
@import myModule;
+@import minmax;
-int main()
-{
-@autoreleasepool
-{
-MyClass *myObject = [MyClass alloc];
-[myObject publicMethod]; // Set breakpoint 0 here.
-}
+int main(int argc, char **argv) {
+ public_func(); // Set breakpoint 0 here.
+ return 0;
}
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/minmax.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/minmax.h?rev=324655&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/minmax.h
(added)
+++
lldb/trunk/packag
[Lldb-commits] [PATCH] D43059: Add implementation for MSVC in CPlusPlusLanguage::IsCPPMangledName
jingham added a comment. We'd get into problems on a platform other than MSVC that uses ^? for symbol names that aren't C++ mangled ones - or equivalently if MSVC uses ^_Z for non-C++ mangled names. It looks like everywhere we use this (or use GuessLanguage) we either turn around and mangle it, and we handle the case where we weren't actually right about that. If we had another language with a different mangling (swift for example) and on some platform that language uses ? for its initial prefix, then we might get into trouble. We don't everywhere do IsCPPMangledName -> Try to demangle -> Try next possible language. So we would miss demangling some names. The "correct" way to do this is to change all the places that use this API actually get the current C++ runtime and ask that if they recognize the name. But right now that's hard because we infer the C++ runtime from the Process (after all you could have both the FSF & LLVM libstdc++'s on the same platform, and you might not know which you will get when you run. Even worse, it used to be (on macOS in the early days of lldb) that you could have two different C++ standard libraries with different manglings. So you can't make a great guess about what mangling is going to be used from just a Target. If we suspected this confusion were a likely problem we'd have to make a TargetLanguageRuntime that you would fall back to if you didn't have a Process, and have that implement IsCPPMangledName. That wouldn't help with two manglings on one platform, but it would keep the platforms properly segregated. OTOH, this seems like a fairly remote possibility, so I'm okay with leaving this as a possible danger, though it might be good to make the comment clearer about that possibility, since the danger it warns about has clearly arisen... Repository: rL LLVM https://reviews.llvm.org/D43059 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42994: Only throw -fPIC when building a shared library
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. This lgtm. If this causes some tests that were previously skipped or xfailed to start passing, you can unskip / unxfail them at the same time. Comment at: packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py:49 os.mkdir(newdir) -except OSError, e: +except OSError as e: if e.errno != os.errno.EEXIST: Weird, does that comma syntax even do anything or was that just a bug? Repository: rL LLVM https://reviews.llvm.org/D42994 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42994: Only throw -fPIC when building a shared library
stella.stamenova added inline comments. Comment at: packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py:49 os.mkdir(newdir) -except OSError, e: +except OSError as e: if e.errno != os.errno.EEXIST: zturner wrote: > Weird, does that comma syntax even do anything or was that just a bug? In python 2.5 or earlier it meant the same as "as" but "as" was not supported. Then for a while (until 3.x) both the comma and "as" meant the same thing and then since 3.x "as" is the only option allowed. Repository: rL LLVM https://reviews.llvm.org/D42994 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43059: Recognize MSVC style mangling in CPlusPlusLanguage::IsCPPMangledName
asmith updated this revision to Diff 133489.
asmith retitled this revision from "Add implementation for MSVC in
CPlusPlusLanguage::IsCPPMangledName" to "Recognize MSVC style mangling in
CPlusPlusLanguage::IsCPPMangledName".
https://reviews.llvm.org/D43059
Files:
source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
Index: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -251,13 +251,17 @@
}
bool CPlusPlusLanguage::IsCPPMangledName(const char *name) {
- // FIXME, we should really run through all the known C++ Language plugins and
- // ask each one if
- // this is a C++ mangled name, but we can put that off till there is actually
- // more than one
- // we care about.
-
- return (name != nullptr && name[0] == '_' && name[1] == 'Z');
+ // FIXME!! we should really run through all the known C++ Language
+ // plugins and ask each one if this is a C++ mangled name
+
+ if (name == nullptr)
+return false;
+
+ // MSVC style mangling
+ if (name[0] == '?')
+return true;
+
+ return (name[0] != '\0' && name[0] == '_' && name[1] == 'Z');
}
bool CPlusPlusLanguage::ExtractContextAndIdentifier(
Index: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -251,13 +251,17 @@
}
bool CPlusPlusLanguage::IsCPPMangledName(const char *name) {
- // FIXME, we should really run through all the known C++ Language plugins and
- // ask each one if
- // this is a C++ mangled name, but we can put that off till there is actually
- // more than one
- // we care about.
-
- return (name != nullptr && name[0] == '_' && name[1] == 'Z');
+ // FIXME!! we should really run through all the known C++ Language
+ // plugins and ask each one if this is a C++ mangled name
+
+ if (name == nullptr)
+return false;
+
+ // MSVC style mangling
+ if (name[0] == '?')
+return true;
+
+ return (name[0] != '\0' && name[0] == '_' && name[1] == 'Z');
}
bool CPlusPlusLanguage::ExtractContextAndIdentifier(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43059: Recognize MSVC style mangling in CPlusPlusLanguage::IsCPPMangledName
zturner accepted this revision.
zturner added a comment.
Looks good. Wish this function took a `StringRef` so you could just say
`return name.startswith("?") || name.startswith("_Z")`
https://reviews.llvm.org/D43059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42443: [SymbolFilePDB] Add support for function symbols
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. Sorry for the delay on this one, looks good. Repository: rL LLVM https://reviews.llvm.org/D42443 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43059: Recognize MSVC style mangling in CPlusPlusLanguage::IsCPPMangledName
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL324672: Recognize MSVC style mangling in
CPlusPlusLanguage::IsCPPMangledName (authored by asmith, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D43059?vs=133489&id=133503#toc
Repository:
rL LLVM
https://reviews.llvm.org/D43059
Files:
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -251,13 +251,17 @@
}
bool CPlusPlusLanguage::IsCPPMangledName(const char *name) {
- // FIXME, we should really run through all the known C++ Language plugins and
- // ask each one if
- // this is a C++ mangled name, but we can put that off till there is actually
- // more than one
- // we care about.
-
- return (name != nullptr && name[0] == '_' && name[1] == 'Z');
+ // FIXME!! we should really run through all the known C++ Language
+ // plugins and ask each one if this is a C++ mangled name
+
+ if (name == nullptr)
+return false;
+
+ // MSVC style mangling
+ if (name[0] == '?')
+return true;
+
+ return (name[0] != '\0' && name[0] == '_' && name[1] == 'Z');
}
bool CPlusPlusLanguage::ExtractContextAndIdentifier(
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -251,13 +251,17 @@
}
bool CPlusPlusLanguage::IsCPPMangledName(const char *name) {
- // FIXME, we should really run through all the known C++ Language plugins and
- // ask each one if
- // this is a C++ mangled name, but we can put that off till there is actually
- // more than one
- // we care about.
-
- return (name != nullptr && name[0] == '_' && name[1] == 'Z');
+ // FIXME!! we should really run through all the known C++ Language
+ // plugins and ask each one if this is a C++ mangled name
+
+ if (name == nullptr)
+return false;
+
+ // MSVC style mangling
+ if (name[0] == '?')
+return true;
+
+ return (name[0] != '\0' && name[0] == '_' && name[1] == 'Z');
}
bool CPlusPlusLanguage::ExtractContextAndIdentifier(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
asmith created this revision.
asmith added reviewers: zturner, lldb-commits.
Herald added subscribers: hintonda, mgorny.
This is modeled after the clang and llvm lit tests.
Several properties have CMAKE_CFG_INTDIR as part of the path - this works
correctly when the cmake generator only supports one configuration which is
known at configuration time, but it does not work correctly when the cmake
generator supports multiple configurations (for example, VS).
For VS, CMAKE_CFG_INTDIR ends up set as $Configuration and then it is never
updated correctly. Instead, the lit configuration can use a property that can
be overwritten at run time. AddLLVM does that for several properties (such as
LLVM_TOOLS_DIR).
This change is also removing properties from the lit/CMakeLists.txt that are
actually set during the call to configure_lit_site_cfg
https://reviews.llvm.org/D43096
Files:
lit/CMakeLists.txt
lit/lit.site.cfg.in
Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -6,8 +6,8 @@
config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
config.lldb_obj_root = "@LLDB_BINARY_DIR@"
-config.lldb_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lldb_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
+config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
config.target_triple = "@TARGET_TRIPLE@"
config.python_executable = "@PYTHON_EXECUTABLE@"
config.cc = "@LLDB_TEST_C_COMPILER@"
@@ -19,6 +19,10 @@
try:
config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
+config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
+config.cc = config.cc % lit_config.params
+config.cxx = config.cxx % lit_config.params
except KeyError as e:
key, = e.args
lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" %
(key,key))
Index: lit/CMakeLists.txt
===
--- lit/CMakeLists.txt
+++ lit/CMakeLists.txt
@@ -1,10 +1,17 @@
-set(LLVM_SOURCE_DIR "${LLVM_MAIN_SRC_DIR}")
-set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
-set(LLVM_BUILD_MODE "%(build_mode)s")
-set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-set(LLVM_LIBS_DIR
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/%(build_config)s")
-set(CLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/..")
-set(CLANG_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/..")
+# Test runner infrastructure for LLDB. This configures the LLDB test trees
+# for use by Lit, and delegates to LLVM's lit test handlers.
+
+if (CMAKE_CFG_INTDIR STREQUAL ".")
+ set(LLVM_BUILD_MODE ".")
+else ()
+ set(LLVM_BUILD_MODE "%(build_mode)s")
+endif ()
+
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_C_COMPILER
${LLDB_TEST_C_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_CXX_COMPILER
${LLDB_TEST_CXX_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR
${LLVM_LIBRARY_OUTPUT_INTDIR})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR
${LLVM_RUNTIME_OUTPUT_INTDIR})
+
if(BUILD_SHARED_LIBS)
set(ENABLE_SHARED 1)
else()
Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -6,8 +6,8 @@
config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
config.lldb_obj_root = "@LLDB_BINARY_DIR@"
-config.lldb_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lldb_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
+config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
config.target_triple = "@TARGET_TRIPLE@"
config.python_executable = "@PYTHON_EXECUTABLE@"
config.cc = "@LLDB_TEST_C_COMPILER@"
@@ -19,6 +19,10 @@
try:
config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
+config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
+config.cc = config.cc % lit_config.params
+config.cxx = config.cxx % lit_config.params
except KeyError as e:
key, = e.args
lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key))
Index: lit/CMakeLists.txt
===
--- lit/CMakeLists.txt
+++ lit/CMakeLists.txt
@@ -1,10 +1,17 @@
-set(LLVM_SOURCE_DIR "${LLVM_MAIN_SRC_DIR}")
-set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
-set(LLVM_BUILD_MODE "%(build_mode)s")
-set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-set(LLVM_LIBS_DIR "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/%(build_config)s")
-set(CLANG_SOURCE_DIR "${CMAKE_CURRENT_SOU
[Lldb-commits] [PATCH] D43099: Make LLDB's clang module cache path customizable
aprantl created this revision.
aprantl added a reviewer: jingham.
This patch makes LLDB's clang module cache path customizable via `settings set
target.clang-modules-cache-path ` and uses it in the LLDB testsuite to
reuse the same location inside the build directory for LLDB and clang.
https://reviews.llvm.org/D43099
Files:
include/lldb/Target/Target.h
packages/Python/lldbsuite/test/lldbtest.py
source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
source/Target/Target.cpp
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -3509,6 +3509,9 @@
OptionValue::eTypeString, nullptr, nullptr,
"A list of trap handler function names, e.g. a common Unix user process "
"one is _sigtramp."},
+{"clang-modules-cache-path",
+ OptionValue::eTypeFileSpec, false, 0, nullptr, nullptr,
+ "The path to the clang modules cache directory (-fmodules-cache-path)."},
{"display-runtime-support-values", OptionValue::eTypeBoolean, false, false,
nullptr, nullptr, "If true, LLDB will show variables that are meant to "
"support the operation of a language's runtime "
@@ -3558,6 +3561,7 @@
ePropertyMemoryModuleLoadLevel,
ePropertyDisplayExpressionsInCrashlogs,
ePropertyTrapHandlerNames,
+ ePropertyClangModulesCachePath,
ePropertyDisplayRuntimeSupportValues,
ePropertyNonStopModeEnabled,
ePropertyExperimental
@@ -3937,6 +3941,15 @@
return option_value->GetCurrentValue();
}
+FileSpec &TargetProperties::GetClangModulesCachePath() {
+ const uint32_t idx = ePropertyClangModulesCachePath;
+ OptionValueFileSpec *option_value =
+ m_collection_sp->GetPropertyAtIndexAsOptionValueFileSpec(nullptr, false,
+ idx);
+ assert(option_value);
+ return option_value->GetCurrentValue();
+}
+
FileSpecList &TargetProperties::GetClangModuleSearchPaths() {
const uint32_t idx = ePropertyClangModuleSearchPaths;
OptionValueFileSpecList *option_value =
Index: source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -590,14 +590,17 @@
// Add additional search paths with { "-I", path } or { "-F", path } here.
{
-llvm::SmallString<128> DefaultModuleCache;
-const bool erased_on_reboot = false;
-llvm::sys::path::system_temp_directory(erased_on_reboot,
- DefaultModuleCache);
-llvm::sys::path::append(DefaultModuleCache, "org.llvm.clang");
-llvm::sys::path::append(DefaultModuleCache, "ModuleCache");
+llvm::SmallString<128> Path;
+target.GetClangModulesCachePath().GetPath(Path);
+if (Path.empty()) {
+ // This code is copied from the Clang driver.
+ const bool erased_on_reboot = false;
+ llvm::sys::path::system_temp_directory(erased_on_reboot, Path);
+ llvm::sys::path::append(Path, "org.llvm.clang");
+ llvm::sys::path::append(Path, "ModuleCache");
+}
std::string module_cache_argument("-fmodules-cache-path=");
-module_cache_argument.append(DefaultModuleCache.str().str());
+module_cache_argument.append(Path.str());
compiler_invocation_arguments.push_back(module_cache_argument);
}
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -859,6 +859,10 @@
self.darwinWithFramework = False
self.makeBuildDir()
+# set the clang modules cache path.
+mod_cache = os.path.join(self.getBuildDir(), "module-cache")
+self.runCmd("settings set target.clang-modules-cache-path " +
mod_cache)
+
def setAsync(self, value):
""" Sets async mode to True/False and ensures it is reset after the
testcase completes."""
old_async = self.dbg.GetAsync()
Index: include/lldb/Target/Target.h
===
--- include/lldb/Target/Target.h
+++ include/lldb/Target/Target.h
@@ -126,6 +126,8 @@
FileSpecList &GetDebugFileSearchPaths();
+ FileSpec &GetClangModulesCachePath();
+
FileSpecList &GetClangModuleSearchPaths();
bool GetEnableAutoImportClangModules() const;
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -3509,6 +3509,9 @@
OptionValue::eTypeString, nullptr, nullptr,
"A list of trap handler function names, e.g. a common Unix user process "
"one is _sigtramp."},
+{"clang-modules-cache-path",
+ OptionValue::eTypeFileSpec, false, 0, null
[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
zturner added inline comments.
Comment at: lit/CMakeLists.txt:10-13
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_C_COMPILER
${LLDB_TEST_C_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_CXX_COMPILER
${LLDB_TEST_CXX_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR
${LLVM_LIBRARY_OUTPUT_INTDIR})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR
${LLVM_RUNTIME_OUTPUT_INTDIR})
This only works if you're using a just-built clang, which might not be the
case. In fact, it's usually not the case, because it's common to want to run
the test suite against a debug build of lldb but using a release build of clang
(otherwise you'll be there all day waiting for it to finish).
I feel like if the user specifies an absolute path to the test compiler on the
command line, that should be what it uses -- always. If we want to use a just
built toolchain, maybe we need something else, like
`-DLLDB_TEST_BUILT_CLANG=ON`, which would trigger this logic.
As I don't use this configuration though, I'm interested in hearing your
thoughts.
https://reviews.llvm.org/D43096
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43099: Make LLDB's clang module cache path customizable
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
Think about whether it would be better to have GetClangModulesCachePath
calculate the fallback modules path rather than having the client do it?
Comment at:
source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp:595-601
+if (Path.empty()) {
+ // This code is copied from the Clang driver.
+ const bool erased_on_reboot = false;
+ llvm::sys::path::system_temp_directory(erased_on_reboot, Path);
+ llvm::sys::path::append(Path, "org.llvm.clang");
+ llvm::sys::path::append(Path, "ModuleCache");
+}
Is there a reason not to have GetClangModulesCachePath do this? This is
roughly the "default value" of the value. Is there a good reason to make
clients compute that?
I presume you are computing this here because clang doesn't offer an API to do
that?
https://reviews.llvm.org/D43099
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
stella.stamenova added inline comments.
Comment at: lit/CMakeLists.txt:10-13
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_C_COMPILER
${LLDB_TEST_C_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_CXX_COMPILER
${LLDB_TEST_CXX_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR
${LLVM_LIBRARY_OUTPUT_INTDIR})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR
${LLVM_RUNTIME_OUTPUT_INTDIR})
zturner wrote:
> This only works if you're using a just-built clang, which might not be the
> case. In fact, it's usually not the case, because it's common to want to run
> the test suite against a debug build of lldb but using a release build of
> clang (otherwise you'll be there all day waiting for it to finish).
>
> I feel like if the user specifies an absolute path to the test compiler on
> the command line, that should be what it uses -- always. If we want to use a
> just built toolchain, maybe we need something else, like
> `-DLLDB_TEST_BUILT_CLANG=ON`, which would trigger this logic.
>
> As I don't use this configuration though, I'm interested in hearing your
> thoughts.
It actually does work in the case when a user specifies a compiler on the
command line as well as when the just-built clang is used and the default today
is to use the just-built clang.
As far as I can tell, you can specify the compiler with LLDB_TEST_C_COMPILER
(or LLDB_TEST_CXX_COMPILER) when calling CMake or by passing a value to the
tests directly with -C. I assume that you are concerned about the first case -
when passing the property to CMake?
In that case LLDB_TEST_C_COMPILER is set to /path/to/compiler and these lines
won't actually affect it - unless for some reason the path contained
${CMAKE_CFG_INTDIR}. If ${CMAKE_CFG_INTDIR} is a period, which is the likely
scenario, it will just be replaced by another period since the build mode would
be the same.
The only case when it might not work is if ${CMAKE_CFG_INTDIR} is in the path
but not a period - but that is unlikely since the scenario would mean that
${CMAKE_CFG_INTDIR} is, say, $Configuration and the path that the user
specified contains $Configuration AND it is different than the one they're
using for LLDB.
On the other hand, without this change it is not possible to use the just-built
compiler when using Visual Studio, for example, because the path to the just
built compiler is not being set correctly and this particular substitution
needs to happen here.
The way to make sure that both scenarios work always is to guard against the
substitution when the user explicitly specifies a path or to enforce the
sibstitution when they're using the just-built clang so a property like
LLDB_TEST_BUILD_CLANG would work. If you think that the error scenario is
likely enough, then we should add the property.
https://reviews.llvm.org/D43096
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
stella.stamenova added inline comments.
Comment at: lit/CMakeLists.txt:10-13
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_C_COMPILER
${LLDB_TEST_C_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_CXX_COMPILER
${LLDB_TEST_CXX_COMPILER})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR
${LLVM_LIBRARY_OUTPUT_INTDIR})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR
${LLVM_RUNTIME_OUTPUT_INTDIR})
stella.stamenova wrote:
> zturner wrote:
> > This only works if you're using a just-built clang, which might not be the
> > case. In fact, it's usually not the case, because it's common to want to
> > run the test suite against a debug build of lldb but using a release build
> > of clang (otherwise you'll be there all day waiting for it to finish).
> >
> > I feel like if the user specifies an absolute path to the test compiler on
> > the command line, that should be what it uses -- always. If we want to use
> > a just built toolchain, maybe we need something else, like
> > `-DLLDB_TEST_BUILT_CLANG=ON`, which would trigger this logic.
> >
> > As I don't use this configuration though, I'm interested in hearing your
> > thoughts.
> It actually does work in the case when a user specifies a compiler on the
> command line as well as when the just-built clang is used and the default
> today is to use the just-built clang.
>
> As far as I can tell, you can specify the compiler with LLDB_TEST_C_COMPILER
> (or LLDB_TEST_CXX_COMPILER) when calling CMake or by passing a value to the
> tests directly with -C. I assume that you are concerned about the first case
> - when passing the property to CMake?
>
> In that case LLDB_TEST_C_COMPILER is set to /path/to/compiler and these lines
> won't actually affect it - unless for some reason the path contained
> ${CMAKE_CFG_INTDIR}. If ${CMAKE_CFG_INTDIR} is a period, which is the likely
> scenario, it will just be replaced by another period since the build mode
> would be the same.
>
> The only case when it might not work is if ${CMAKE_CFG_INTDIR} is in the path
> but not a period - but that is unlikely since the scenario would mean that
> ${CMAKE_CFG_INTDIR} is, say, $Configuration and the path that the user
> specified contains $Configuration AND it is different than the one they're
> using for LLDB.
>
> On the other hand, without this change it is not possible to use the
> just-built compiler when using Visual Studio, for example, because the path
> to the just built compiler is not being set correctly and this particular
> substitution needs to happen here.
>
> The way to make sure that both scenarios work always is to guard against the
> substitution when the user explicitly specifies a path or to enforce the
> sibstitution when they're using the just-built clang so a property like
> LLDB_TEST_BUILD_CLANG would work. If you think that the error scenario is
> likely enough, then we should add the property.
>
Actually, I misspoke. There is another way to do it without an extra property
that the user has to pass.
Right now, in the main CMakeLists.txt for LLDB, we create a property
LLDB_DEFAULT_TEST_C_COMPILER which overwrites LLDB_TEST_C_COMPILER if
LLDB_TEST_C_COMPILER is not set by the user. We could at that point first check
whether LLDB_TEST_C_COMPILER was explicitly set and internally create a
property to tell us whether to overwrite later. I think that may actually be
better since it maintains the current behavior and there's no need for a new
explicit property.
Thoughts?
https://reviews.llvm.org/D43096
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
The problem is that CMAKE_CFG_INTDIR evaluates to something very common,
like “Debug” or “Release”, and replacing a common string like that in a
path creates more problems than it solves in my opinion. What if your build
dir is C:\src\LLDBDebugger\out\Debug\clang.exe? Debug appears twice in this
string so a replace might have unexpected results.
More importantly though, what if you *dont* want to use the just built
compiler? Maybe you specifically want to use the one from the release dir
because it’s faster, but your lldb is in the debug dir?
What if we say that if LLDB_TEST_JUST_BUILT_CLANG is ON, it initializes
these values as you’re doing now, but if you specify them manually it uses
exactly what you specify with no replacement? Would that work? (Having one
variable also saves some typing on the command line anyway)
On Thu, Feb 8, 2018 at 8:24 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added inline comments.
>
>
>
> Comment at: lit/CMakeLists.txt:10-13
> +string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE}
> LLDB_TEST_C_COMPILER ${LLDB_TEST_C_COMPILER})
> +string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE}
> LLDB_TEST_CXX_COMPILER ${LLDB_TEST_CXX_COMPILER})
> +string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR
> ${LLVM_LIBRARY_OUTPUT_INTDIR})
> +string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR
> ${LLVM_RUNTIME_OUTPUT_INTDIR})
>
> zturner wrote:
> > This only works if you're using a just-built clang, which might not be
> the case. In fact, it's usually not the case, because it's common to want
> to run the test suite against a debug build of lldb but using a release
> build of clang (otherwise you'll be there all day waiting for it to finish).
> >
> > I feel like if the user specifies an absolute path to the test compiler
> on the command line, that should be what it uses -- always. If we want to
> use a just built toolchain, maybe we need something else, like
> `-DLLDB_TEST_BUILT_CLANG=ON`, which would trigger this logic.
> >
> > As I don't use this configuration though, I'm interested in hearing your
> thoughts.
> It actually does work in the case when a user specifies a compiler on the
> command line as well as when the just-built clang is used and the default
> today is to use the just-built clang.
>
> As far as I can tell, you can specify the compiler with
> LLDB_TEST_C_COMPILER (or LLDB_TEST_CXX_COMPILER) when calling CMake or by
> passing a value to the tests directly with -C. I assume that you are
> concerned about the first case - when passing the property to CMake?
>
> In that case LLDB_TEST_C_COMPILER is set to /path/to/compiler and these
> lines won't actually affect it - unless for some reason the path contained
> ${CMAKE_CFG_INTDIR}. If ${CMAKE_CFG_INTDIR} is a period, which is the
> likely scenario, it will just be replaced by another period since the build
> mode would be the same.
>
> The only case when it might not work is if ${CMAKE_CFG_INTDIR} is in the
> path but not a period - but that is unlikely since the scenario would mean
> that ${CMAKE_CFG_INTDIR} is, say, $Configuration and the path that the user
> specified contains $Configuration AND it is different than the one they're
> using for LLDB.
>
> On the other hand, without this change it is not possible to use the
> just-built compiler when using Visual Studio, for example, because the path
> to the just built compiler is not being set correctly and this particular
> substitution needs to happen here.
>
> The way to make sure that both scenarios work always is to guard against
> the substitution when the user explicitly specifies a path or to enforce
> the sibstitution when they're using the just-built clang so a property like
> LLDB_TEST_BUILD_CLANG would work. If you think that the error scenario is
> likely enough, then we should add the property.
>
>
>
> https://reviews.llvm.org/D43096
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42443: [SymbolFilePDB] Add support for function symbols
asmith updated this revision to Diff 133561.
asmith added a comment.
Minor cleanup before commit
https://reviews.llvm.org/D42443
Files:
lit/SymbolFile/PDB/Inputs/FuncSymbols.cpp
lit/SymbolFile/PDB/Inputs/FuncSymbolsTestMain.cpp
lit/SymbolFile/PDB/Inputs/SimpleTypesTest.cpp
lit/SymbolFile/PDB/func-symbols.test
source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -10,6 +10,7 @@
#ifndef lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
#define lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
+#include "lldb/Core/UniqueCStringMap.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Utility/UserID.h"
@@ -181,6 +182,19 @@
void FindTypesByName(const std::string &name, uint32_t max_matches,
lldb_private::TypeMap &types);
+ lldb::CompUnitSP
+ GetCompileUnitContainsAddress(const lldb_private::Address &so_addr);
+
+ typedef std::vector TypeCollection;
+
+ void
+ GetTypesForPDBSymbol(const llvm::pdb::PDBSymbol *pdb_symbol,
+ uint32_t type_mask, TypeCollection &type_collection);
+
+ lldb_private::Function* ParseCompileUnitFunctionForPDBFunc(
+ const llvm::pdb::PDBSymbolFunc *pdb_func,
+ const lldb_private::SymbolContext &sc);
+
void GetCompileUnitIndex(const llvm::pdb::PDBSymbolCompiland *pdb_compiland,
uint32_t &index);
@@ -190,14 +204,33 @@
std::unique_ptr
GetPDBCompilandByUID(uint32_t uid);
+ lldb_private::Mangled
+ GetMangledForPDBFunc(const llvm::pdb::PDBSymbolFunc *pdb_func);
+
+ bool ResolveFunction(llvm::pdb::PDBSymbolFunc *pdb_func,
+ bool include_inlines,
+ lldb_private::SymbolContextList &sc_list);
+
+ bool ResolveFunction(uint32_t uid, bool include_inlines,
+ lldb_private::SymbolContextList &sc_list);
+
+ void CacheFunctionNames();
+
+ bool DeclContextMatchesThisSymbolFile(
+ const lldb_private::CompilerDeclContext *decl_ctx);
+
llvm::DenseMap m_comp_units;
llvm::DenseMap m_types;
std::vector m_builtin_types;
std::unique_ptr m_session_up;
std::unique_ptr m_global_scope_up;
uint32_t m_cached_compile_unit_count;
std::unique_ptr m_tu_decl_ctx_up;
+
+ lldb_private::UniqueCStringMap m_func_full_names;
+ lldb_private::UniqueCStringMap m_func_base_names;
+ lldb_private::UniqueCStringMap m_func_method_names;
};
#endif // lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -30,17 +30,20 @@
#include "llvm/DebugInfo/PDB/IPDBSourceFile.h"
#include "llvm/DebugInfo/PDB/IPDBTable.h"
#include "llvm/DebugInfo/PDB/PDBSymbol.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolBlock.h"
#include "llvm/DebugInfo/PDB/PDBSymbolCompiland.h"
#include "llvm/DebugInfo/PDB/PDBSymbolCompilandDetails.h"
#include "llvm/DebugInfo/PDB/PDBSymbolData.h"
#include "llvm/DebugInfo/PDB/PDBSymbolExe.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFunc.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugEnd.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugStart.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolPublicSymbol.h"
#include "llvm/DebugInfo/PDB/PDBSymbolTypeEnum.h"
#include "llvm/DebugInfo/PDB/PDBSymbolTypeTypedef.h"
#include "llvm/DebugInfo/PDB/PDBSymbolTypeUDT.h"
+#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
#include "Plugins/SymbolFile/PDB/PDBASTParser.h"
#include
@@ -261,10 +264,66 @@
return TranslateLanguage(details->getLanguage());
}
+lldb_private::Function *
+SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc(
+const PDBSymbolFunc *pdb_func,
+const lldb_private::SymbolContext &sc) {
+ assert(pdb_func != nullptr);
+ lldbassert(sc.comp_unit && sc.module_sp.get());
+
+ auto file_vm_addr = pdb_func->getVirtualAddress();
+ if (file_vm_addr == LLDB_INVALID_ADDRESS)
+return nullptr;
+
+ auto func_length = pdb_func->getLength();
+ AddressRange func_range = AddressRange(file_vm_addr,
+ func_length,
+ sc.module_sp->GetSectionList());
+ if (!func_range.GetBaseAddress().IsValid())
+return nullptr;
+
+ user_id_t func_type_uid = pdb_func->getSignatureId();
+ // TODO: Function symbol with invalid signature won't be handled. We'll set up
+ // a white list to trace them.
+ if (!pdb_func->getSignature())
+return nullptr;
+
+ lldb_private::Type* func_type = ResolveTypeUID(pdb_func->getSymIndexId());
+ if (!func_type)
+return nullptr;
+
+ Mangled mangled = GetMangledFor
[Lldb-commits] [PATCH] D42443: [SymbolFilePDB] Add support for function symbols
This revision was automatically updated to reflect the committed changes.
Closed by commit rL324707: [SymbolFilePDB] Add support for function symbols
(authored by asmith, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D42443?vs=133561&id=133562#toc
Repository:
rL LLVM
https://reviews.llvm.org/D42443
Files:
lldb/trunk/lit/SymbolFile/PDB/Inputs/FuncSymbols.cpp
lldb/trunk/lit/SymbolFile/PDB/Inputs/FuncSymbolsTestMain.cpp
lldb/trunk/lit/SymbolFile/PDB/Inputs/SimpleTypesTest.cpp
lldb/trunk/lit/SymbolFile/PDB/func-symbols.test
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -10,6 +10,7 @@
#ifndef lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
#define lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
+#include "lldb/Core/UniqueCStringMap.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Utility/UserID.h"
@@ -181,6 +182,19 @@
void FindTypesByName(const std::string &name, uint32_t max_matches,
lldb_private::TypeMap &types);
+ lldb::CompUnitSP
+ GetCompileUnitContainsAddress(const lldb_private::Address &so_addr);
+
+ typedef std::vector TypeCollection;
+
+ void
+ GetTypesForPDBSymbol(const llvm::pdb::PDBSymbol *pdb_symbol,
+ uint32_t type_mask, TypeCollection &type_collection);
+
+ lldb_private::Function* ParseCompileUnitFunctionForPDBFunc(
+ const llvm::pdb::PDBSymbolFunc *pdb_func,
+ const lldb_private::SymbolContext &sc);
+
void GetCompileUnitIndex(const llvm::pdb::PDBSymbolCompiland *pdb_compiland,
uint32_t &index);
@@ -190,14 +204,33 @@
std::unique_ptr
GetPDBCompilandByUID(uint32_t uid);
+ lldb_private::Mangled
+ GetMangledForPDBFunc(const llvm::pdb::PDBSymbolFunc *pdb_func);
+
+ bool ResolveFunction(llvm::pdb::PDBSymbolFunc *pdb_func,
+ bool include_inlines,
+ lldb_private::SymbolContextList &sc_list);
+
+ bool ResolveFunction(uint32_t uid, bool include_inlines,
+ lldb_private::SymbolContextList &sc_list);
+
+ void CacheFunctionNames();
+
+ bool DeclContextMatchesThisSymbolFile(
+ const lldb_private::CompilerDeclContext *decl_ctx);
+
llvm::DenseMap m_comp_units;
llvm::DenseMap m_types;
std::vector m_builtin_types;
std::unique_ptr m_session_up;
std::unique_ptr m_global_scope_up;
uint32_t m_cached_compile_unit_count;
std::unique_ptr m_tu_decl_ctx_up;
+
+ lldb_private::UniqueCStringMap m_func_full_names;
+ lldb_private::UniqueCStringMap m_func_base_names;
+ lldb_private::UniqueCStringMap m_func_method_names;
};
#endif // lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -30,17 +30,20 @@
#include "llvm/DebugInfo/PDB/IPDBSourceFile.h"
#include "llvm/DebugInfo/PDB/IPDBTable.h"
#include "llvm/DebugInfo/PDB/PDBSymbol.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolBlock.h"
#include "llvm/DebugInfo/PDB/PDBSymbolCompiland.h"
#include "llvm/DebugInfo/PDB/PDBSymbolCompilandDetails.h"
#include "llvm/DebugInfo/PDB/PDBSymbolData.h"
#include "llvm/DebugInfo/PDB/PDBSymbolExe.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFunc.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugEnd.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugStart.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolPublicSymbol.h"
#include "llvm/DebugInfo/PDB/PDBSymbolTypeEnum.h"
#include "llvm/DebugInfo/PDB/PDBSymbolTypeTypedef.h"
#include "llvm/DebugInfo/PDB/PDBSymbolTypeUDT.h"
+#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
#include "Plugins/SymbolFile/PDB/PDBASTParser.h"
#include
@@ -261,10 +264,66 @@
return TranslateLanguage(details->getLanguage());
}
+lldb_private::Function *
+SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc(
+const PDBSymbolFunc *pdb_func,
+const lldb_private::SymbolContext &sc) {
+ assert(pdb_func != nullptr);
+ lldbassert(sc.comp_unit && sc.module_sp.get());
+
+ auto file_vm_addr = pdb_func->getVirtualAddress();
+ if (file_vm_addr == LLDB_INVALID_ADDRESS)
+return nullptr;
+
+ auto func_length = pdb_func->getLength();
+ AddressRange func_range = AddressRange(file_vm_addr,
+ func_length,
+ sc.module_sp->GetSectionList());
+ if (!func_range.GetBaseAddress().IsValid())
+return nullptr;
+
+ user_id_t func_type_uid = pdb_func->getSig
