Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
On Thu, 8 Mar 2018 at 02:46, Davide Italiano wrote: > On Wed, Mar 7, 2018 at 6:39 PM, Jim Ingham wrote: > > The hashing algorithm gives different values - at least for foobár - > between the two implementations. So if you build with an older clang, and > test with a new lldb, the type lookup fails. > > > When I landed this patch, the two algorithms were identical, but this wasn't always the case. The llvm's version of the algorithm used to be nondeterministic (as in, it's result depended on the signedness of char on your platform). This was recently fixed, and this patch was meant to make sure they always stay in sync. We considered a couple of options when we noticed this discrepancy, but since this had never really worked (llvm and lldb had always disagreed on the hash value of strings with high bit set) and nobody noticed, we decided to just fix the llvm implementation. The other option was to create a signedDJBHash function, and make lldb&llvm always use that for apple accelerator tables. I guess it's still not too late to do that > > This is not my case, I think? I'm building from the monorepo so clang > and lldb are supposed to be in sync (in fact, the version of clang in > my test is 7.0). > > My best (and only) guess would be that this is because of different versions of dsymutil (we are using the system dsymutil to build the dsym bundle), though I'm not sure then why the test doesn't fail for me as well, as I have the stock dsymutil that ships which XCode, which presumably still has the broken hash function. Could you send me the main.o and a.out.dSYM files that are built by this test (or at least the output of running llvm-dwarfdump -apple-types on them), so I can compare them with mine? The interesting question is what does "foobár" hash to (for me it's 0xba721fe1 in both files). ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
labath added inline comments.
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:3500-3518
+ // Create a list of write entries from loadable segments,
+ // using physical addresses if they aren't all null
+ size_t header_count = ParseProgramHeaders();
+ bool should_use_paddr = AnySegmentHasPhysicalAddress();
+ for (size_t i = 1; i <= header_count; ++i) {
+Process::WriteEntry entry;
+auto header = GetProgramHeaderByIndex(i);
This is the only part that's ELF-specific. Could we factor this out into a
separate function (and leave the common part in ObjectFile)? Besides reducing
duplication this will also make it easier to remove the
Target/Process/RegisterContext uses from the ObjectFile in the future, as there
will be just a single place that needs to be updated.
https://reviews.llvm.org/D42145
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44166: [SymbolFilePDB] Add missing Char16 and Char32 types in a few places
zturner added a subscriber: asmith. zturner added a comment. Lgtm Repository: rL LLVM https://reviews.llvm.org/D44166 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43837: Move option parsing out of the Args class
labath added a comment. Is there anything else you wanted me to do here? https://reviews.llvm.org/D43837 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r327013 - [LLDB][PPC64] Fix single step and LldbGdbServer tests
Author: labath
Date: Thu Mar 8 07:41:13 2018
New Revision: 327013
URL: http://llvm.org/viewvc/llvm-project?rev=327013&view=rev
Log:
[LLDB][PPC64] Fix single step and LldbGdbServer tests
Summary:
On PPC64, the tested functions were being entered through their local entry
point, while the tests expected the program to stop at the function start
address, that, for PPC64, corresponds to the global entry point.
To fix the issue, the test program was modified to call the functions to be
tested through function pointers, which, on PPC64, force the calls through the
global entry point, while not affecting the test on other platforms.
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43768
Patch by Leandro Lupori .
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py?rev=327013&r1=327012&r2=327013&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
Thu Mar 8 07:41:13 2018
@@ -331,7 +331,7 @@ class LldbGdbServerTestCase(gdbremote_te
self.assertTrue('pc' in generic_regs)
# Ensure we have a frame pointer register. PPC64le's FP is the same as
SP
-if(self.getArchitecture() != 'powerpc64le'):
+if self.getArchitecture() != 'powerpc64le':
self.assertTrue('fp' in generic_regs)
# Ensure we have a stack pointer register.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py?rev=327013&r1=327012&r2=327013&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
Thu Mar 8 07:41:13 2018
@@ -1008,9 +1008,10 @@ class GdbRemoteTestCaseBase(TestBase):
reg_info["name"] in PREFERRED_REGISTER_NAMES):
# We found a preferred register. Use it.
return reg_info["lldb_register_index"]
-if ("generic" in reg_info) and (reg_info["generic"] == "fp"):
-# A frame pointer register will do as a register to modify
-# temporarily.
+if ("generic" in reg_info) and (reg_info["generic"] == "fp" or
+reg_info["generic"] == "arg1"):
+# A frame pointer or first arg register will do as a
+# register to modify temporarily.
alternative_register_index = reg_info["lldb_register_index"]
# We didn't find a preferred register. Return whatever alternative
register
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=327013&r1=327012&r2=327013&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 Thu
Mar 8 07:41:13 2018
@@ -303,18 +303,22 @@ int main(int argc, char **argv) {
printf("code address: %p\n", func_p);
pthread_mutex_unlock(&g_print_mutex);
} else if (std::strstr(argv[i], CALL_FUNCTION_PREFIX)) {
+ void (*func_p)() = nullptr;
+
// Defaut to providing the address of main.
if (std::strcmp(argv[i] + strlen(CALL_FUNCTION_PREFIX), "hello") == 0)
-hello();
+func_p = hello;
else if (std::strcmp(argv[i] + strlen(CALL_FUNCTION_PREFIX),
"swap_chars") == 0)
-swap_chars();
+func_p = swap_chars;
else {
pthread_mutex_lock(&g_print_mutex);
printf("unknown function: %s\n",
argv[i] + strlen(CALL_FUNCTION_PREFIX));
pthread_mutex_unlock(&g_print_mutex);
}
+ if (func_p)
+func_p();
} else if (std::strstr(argv[i], THREAD_PREFIX)) {
// Check if we're creating a new thread.
if (std::strstr(argv[i] + strlen(THREAD_PREFIX), THREAD_COMMAND_NEW)) {
___
lldb-commits mailing l
[Lldb-commits] [lldb] r327016 - Install lldb's SB headers (pr36630)
Author: labath
Date: Thu Mar 8 07:52:46 2018
New Revision: 327016
URL: http://llvm.org/viewvc/llvm-project?rev=327016&view=rev
Log:
Install lldb's SB headers (pr36630)
These were removed in r309021 in what looks like an accidentally
committed change. This brings them back.
I also rename the header component to lldb-headers (instead of
lldb_headers) to match the llvm style and add a special
install-lldb-headers target, which installs just the headers.
Modified:
lldb/trunk/cmake/modules/LLDBConfig.cmake
Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=327016&r1=327015&r2=327016&view=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Thu Mar 8 07:52:46 2018
@@ -277,27 +277,31 @@ include_directories(BEFORE
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
install(DIRECTORY include/
-COMPONENT lldb_headers
+COMPONENT lldb-headers
DESTINATION include
FILES_MATCHING
PATTERN "*.h"
PATTERN ".svn" EXCLUDE
PATTERN ".cmake" EXCLUDE
PATTERN "Config.h" EXCLUDE
-PATTERN "lldb-*.h" EXCLUDE
-PATTERN "API/*.h" EXCLUDE
)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/
-COMPONENT lldb_headers
+COMPONENT lldb-headers
DESTINATION include
FILES_MATCHING
PATTERN "*.h"
PATTERN ".svn" EXCLUDE
PATTERN ".cmake" EXCLUDE
-PATTERN "lldb-*.h" EXCLUDE
-PATTERN "API/*.h" EXCLUDE
)
+
+ add_custom_target(lldb-headers)
+ set_target_properties(lldb-headers PROPERTIES FOLDER "Misc")
+
+ if (NOT CMAKE_CONFIGURATION_TYPES)
+add_llvm_install_targets(install-lldb-headers
+ COMPONENT lldb-headers)
+ endif()
endif()
if (NOT LIBXML2_FOUND AND NOT (CMAKE_SYSTEM_NAME MATCHES "Windows"))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r327017 - Fix std unique pointer pretty-printer for new stl versions
Author: labath
Date: Thu Mar 8 08:03:09 2018
New Revision: 327017
URL: http://llvm.org/viewvc/llvm-project?rev=327017&view=rev
Log:
Fix std unique pointer pretty-printer for new stl versions
Summary: The unique pointer layout was changed in libstdc++ 6.0.23.
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: luporl, lbianc, lldb-commits
Differential Revision: https://reviews.llvm.org/D44015
Patch by Alexandre Yukio Yamashita .
Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp?rev=327017&r1=327016&r2=327017&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
(original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp Thu
Mar 8 08:03:09 2018
@@ -43,6 +43,8 @@ private:
ValueObjectSP m_ptr_obj;
ValueObjectSP m_obj_obj;
ValueObjectSP m_del_obj;
+
+ ValueObjectSP GetTuple();
};
} // end of anonymous namespace
@@ -53,17 +55,34 @@ LibStdcppUniquePtrSyntheticFrontEnd::Lib
Update();
}
-bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ValueObjectSP LibStdcppUniquePtrSyntheticFrontEnd::GetTuple() {
ValueObjectSP valobj_backend_sp = m_backend.GetSP();
+
if (!valobj_backend_sp)
-return false;
+return nullptr;
ValueObjectSP valobj_sp = valobj_backend_sp->GetNonSyntheticValue();
if (!valobj_sp)
-return false;
+return nullptr;
- ValueObjectSP tuple_sp =
+ ValueObjectSP obj_child_sp =
valobj_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+ ValueObjectSP obj_subchild_sp =
+ obj_child_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+ // if there is a _M_t subchild, the tuple is found in
+ // the obj_subchild_sp (for libstdc++ 6.0.23).
+ if (obj_subchild_sp) {
+return obj_subchild_sp;
+ }
+
+ return obj_child_sp;
+}
+
+bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ ValueObjectSP tuple_sp = GetTuple();
+
if (!tuple_sp)
return false;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44015: Fix std unique pointer not printing.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL327017: Fix std unique pointer pretty-printer for new stl
versions (authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D44015
Files:
lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
@@ -43,6 +43,8 @@
ValueObjectSP m_ptr_obj;
ValueObjectSP m_obj_obj;
ValueObjectSP m_del_obj;
+
+ ValueObjectSP GetTuple();
};
} // end of anonymous namespace
@@ -53,17 +55,34 @@
Update();
}
-bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ValueObjectSP LibStdcppUniquePtrSyntheticFrontEnd::GetTuple() {
ValueObjectSP valobj_backend_sp = m_backend.GetSP();
+
if (!valobj_backend_sp)
-return false;
+return nullptr;
ValueObjectSP valobj_sp = valobj_backend_sp->GetNonSyntheticValue();
if (!valobj_sp)
-return false;
+return nullptr;
- ValueObjectSP tuple_sp =
+ ValueObjectSP obj_child_sp =
valobj_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+ ValueObjectSP obj_subchild_sp =
+ obj_child_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+ // if there is a _M_t subchild, the tuple is found in
+ // the obj_subchild_sp (for libstdc++ 6.0.23).
+ if (obj_subchild_sp) {
+return obj_subchild_sp;
+ }
+
+ return obj_child_sp;
+}
+
+bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ ValueObjectSP tuple_sp = GetTuple();
+
if (!tuple_sp)
return false;
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
@@ -43,6 +43,8 @@
ValueObjectSP m_ptr_obj;
ValueObjectSP m_obj_obj;
ValueObjectSP m_del_obj;
+
+ ValueObjectSP GetTuple();
};
} // end of anonymous namespace
@@ -53,17 +55,34 @@
Update();
}
-bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ValueObjectSP LibStdcppUniquePtrSyntheticFrontEnd::GetTuple() {
ValueObjectSP valobj_backend_sp = m_backend.GetSP();
+
if (!valobj_backend_sp)
-return false;
+return nullptr;
ValueObjectSP valobj_sp = valobj_backend_sp->GetNonSyntheticValue();
if (!valobj_sp)
-return false;
+return nullptr;
- ValueObjectSP tuple_sp =
+ ValueObjectSP obj_child_sp =
valobj_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+ ValueObjectSP obj_subchild_sp =
+ obj_child_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+ // if there is a _M_t subchild, the tuple is found in
+ // the obj_subchild_sp (for libstdc++ 6.0.23).
+ if (obj_subchild_sp) {
+return obj_subchild_sp;
+ }
+
+ return obj_child_sp;
+}
+
+bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ ValueObjectSP tuple_sp = GetTuple();
+
if (!tuple_sp)
return false;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44253: [SymbolFilePDB] Rewrite ParseTypes method
asmith created this revision.
asmith added reviewers: zturner, rnk, lldb-commits.
Herald added a subscriber: llvm-commits.
The types for the compiland's children are parsed when parsing types for a PDB
compiland. Global types also need to be parsed but unfortunately PDBs do not
have compiland information about each global type. So we parse them all on the
first call to ParseTypes.
If a sc.function is provided then parse the types for that function. Otherwise
parse the types for the overall sc.comp_unit.
The ParseTypes method can be very slow if a program has a long list of compile
units containing needed modules. Debugging clang-cl with lldb will show the
problem.
Repository:
rL LLVM
https://reviews.llvm.org/D44253
Files:
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -438,30 +438,59 @@
size_t SymbolFilePDB::ParseTypes(const lldb_private::SymbolContext &sc) {
lldbassert(sc.module_sp.get());
+ if (!sc.comp_unit)
+return 0;
+
size_t num_added = 0;
- auto results_up = m_session_up->getGlobalScope()->findAllChildren();
- if (!results_up)
+ auto compiland = GetPDBCompilandByUID(sc.comp_unit->GetID());
+ if (!compiland)
return 0;
- while (auto symbol_up = results_up->getNext()) {
-switch (symbol_up->getSymTag()) {
-case PDB_SymType::Enum:
-case PDB_SymType::UDT:
-case PDB_SymType::Typedef:
- break;
-default:
- continue;
-}
-auto type_uid = symbol_up->getSymIndexId();
-if (m_types.find(type_uid) != m_types.end())
- continue;
+ auto ParseTypesByTagFn = [&num_added, this](const PDBSymbol &raw_sym) {
+std::unique_ptr results;
+PDB_SymType tags_to_search[] = { PDB_SymType::Enum, PDB_SymType::Typedef,
+PDB_SymType::UDT };
+for (auto tag : tags_to_search) {
+ results = raw_sym.findAllChildren(tag);
+ if (!results || results->getChildCount() == 0)
+continue;
+ while (auto symbol = results->getNext()) {
+switch (symbol->getSymTag()) {
+case PDB_SymType::Enum:
+case PDB_SymType::UDT:
+case PDB_SymType::Typedef:
+ break;
+default:
+ continue;
+}
-// This should cause the type to get cached and stored in the `m_types`
-// lookup.
-if (!ResolveTypeUID(symbol_up->getSymIndexId()))
- continue;
+// This should cause the type to get cached and stored in the `m_types`
+// lookup.
+if (!ResolveTypeUID(symbol->getSymIndexId()))
+ continue;
-++num_added;
+++num_added;
+ }
+}
+ };
+
+ if (sc.function) {
+auto pdb_func =
+
m_session_up->getConcreteSymbolById(sc.function->GetID());
+if (!pdb_func)
+ return 0;
+ParseTypesByTagFn(*pdb_func);
+ } else {
+ParseTypesByTagFn(*compiland);
+
+// Also parse global types particularly coming from this compiland.
+// Unfortunately, PDB has no compiland information for each global type.
+// We have to parse them all. But ensure we only do this once.
+static bool parse_all_global_types = false;
+if (!parse_all_global_types) {
+ ParseTypesByTagFn(*m_global_scope_up);
+ parse_all_global_types = true;
+}
}
return num_added;
}
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -438,30 +438,59 @@
size_t SymbolFilePDB::ParseTypes(const lldb_private::SymbolContext &sc) {
lldbassert(sc.module_sp.get());
+ if (!sc.comp_unit)
+return 0;
+
size_t num_added = 0;
- auto results_up = m_session_up->getGlobalScope()->findAllChildren();
- if (!results_up)
+ auto compiland = GetPDBCompilandByUID(sc.comp_unit->GetID());
+ if (!compiland)
return 0;
- while (auto symbol_up = results_up->getNext()) {
-switch (symbol_up->getSymTag()) {
-case PDB_SymType::Enum:
-case PDB_SymType::UDT:
-case PDB_SymType::Typedef:
- break;
-default:
- continue;
-}
-auto type_uid = symbol_up->getSymIndexId();
-if (m_types.find(type_uid) != m_types.end())
- continue;
+ auto ParseTypesByTagFn = [&num_added, this](const PDBSymbol &raw_sym) {
+std::unique_ptr results;
+PDB_SymType tags_to_search[] = { PDB_SymType::Enum, PDB_SymType::Typedef,
+PDB_SymType::UDT };
+for (auto tag : tags_to_search) {
+ results = raw_sym.findAllChildren(tag);
+ if (!results || results->getChildCount() == 0)
+continue;
+ while (auto symbol = results->getNext()) {
+switch (symbol->getSymTag()) {
+case PDB_SymType::Enum:
+case PDB_SymType::UDT:
+case PDB_SymType::Typedef:
+
[Lldb-commits] [PATCH] D44157: [elf] Remove one copy of the section merging code
jankratochvil accepted this revision. jankratochvil added a comment. This revision is now accepted and ready to land. Yes, it should be the same I think; some notes of mine: Module::GetSectionList()->obj_file->CreateSections(*GetUnifiedSectionList()); Module::GetUnifiedSectionList()->Module::m_sections_ap.get(); ObjectFileELF::CreateSections()->removal ObjectFileELF::m_sections_ap.get() ---> Module::m_sections_ap.get(); SymbolVendorELF::CreateInstance() ObjectFileSP dsym_objfile_sp->SetType(ObjectFile::eTypeDebugInfo); SymbolVendorELF *symbol_vendor = new SymbolVendorELF(module_sp); dsym_objfile_sp->GetSectionList(); ---> module_sp->GetSectionList(); https://reviews.llvm.org/D44157 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5
clayborg added a comment. In https://reviews.llvm.org/D32167#1026779, @davide wrote: > In https://reviews.llvm.org/D32167#1026762, @jankratochvil wrote: > > > In https://reviews.llvm.org/D32167#1024546, @labath wrote: > > > > > I personally don't think having a new debug info flavour is a good idea. > > > Tests written specifically to test this functionality will be easier to > > > maintain and debug when they break. And keeping adding new flavours for > > > every compiler option is not a viable long term strategy. > > > > > > Here I disagree, from GDB testsuite experience I find more wider testing > > always better as it will better catch bugs even in unrelated new > > functionalities being implemented in the future. One can never guess all > > the combinations in advance - if one could then one needs no regression > > testing at all. There are more than enough CPU cycles available for > > testing. I find rather a serious problem racy==unreliable test results > > which waste human efforts investigating the results and with more parallel > > testing (make -j) and virtualized infrastructure the racy results happen > > even more often. As an example one racy testcase I idenitifed is: > > > > > > packages/Python/lldbsuite/test/functionalities/signal/handle-segv/TestHandleSegv.py > > line 33: AssertionError: 4 != 5 (eStateLaunching != eStateStopped) > > > > > > I think at least these test are racy: > > > > BreakpointAfterJoinTestCase-test > >CreateDuringStepTestCase-test_step_inst_with > >HandleSegvTestCase-test_inferior_handle_sigsegv > >ReturnValueTestCase-test_vector_values > >TestTargetSymbolsBuildidSymlink-test_target_symbols_buildid > >ThreadSpecificBreakPlusConditionTestCase-test_python > >ThreadSpecificBreakTestCase-test_python > >ThreadStateTestCase-test_process_interrupt > > > > > I'm not necessarily convinced having another column in the matrix is > something that can substitute targeted testing. If I would have done targeted testing I wouldn't have caught the breakpoint issue that came up with this patch. So I agree with jankratochvil that it is best to test this all the way by adding another row. There is no way we can guess what certain compilers will do and and all the different permutations this can cause. Not sure where ".debug_types" lands in terms of popularity, but I would guess it comes in above other DWARF flavors (dwo, dwz). Can I at least land this and then we can work on future improvements to the rows required. This is only currently enabled on linux where we tend to have fast buildbots. Darwin compilers don't support this with mach-o due to the 255 section limit that mach-o suffers from. https://reviews.llvm.org/D32167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
owenpshaw updated this revision to Diff 137598.
owenpshaw added a comment.
- Share some common code in LoadInMemory
The DoLoadInMemory implementations call target.CalculateProcess() again, but
passing Process or Process::WriteEntries to DoLoadInMemory would require either
moving the Process.h include to ObjectFile.h or using forward declarations and
pointers. Calling CalculateProcess felt like the lest intrusive option and has
little cost. Open to other options.
https://reviews.llvm.org/D42145
Files:
include/lldb/Host/XML.h
include/lldb/Symbol/ObjectFile.h
include/lldb/Target/MemoryRegionInfo.h
include/lldb/Target/Process.h
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteLoad.py
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
source/Host/common/XML.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
source/Symbol/ObjectFile.cpp
source/Target/Process.cpp
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -2533,6 +2533,17 @@
return 0;
}
+Status Process::WriteObjectFile(std::vector entries) {
+ Status error;
+ for (const auto &Entry : entries) {
+WriteMemory(Entry.Dest, Entry.Contents.data(), Entry.Contents.size(),
+error);
+if (!error.Success())
+ break;
+ }
+ return error;
+}
+
#define USE_ALLOCATE_MEMORY_CACHE 1
addr_t Process::AllocateMemory(size_t size, uint32_t permissions,
Status &error) {
Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -656,25 +656,11 @@
if (set_pc && !GetEntryPointAddress().IsValid())
return Status("No entry address in object file");
- SectionList *section_list = GetSectionList();
- if (!section_list)
-return Status("No section in object file");
- size_t section_count = section_list->GetNumSections(0);
- for (size_t i = 0; i < section_count; ++i) {
-SectionSP section_sp = section_list->GetSectionAtIndex(i);
-addr_t addr = target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
-if (addr != LLDB_INVALID_ADDRESS) {
- DataExtractor section_data;
- // We can skip sections like bss
- if (section_sp->GetFileSize() == 0)
-continue;
- section_sp->GetSectionData(section_data);
- lldb::offset_t written = process->WriteMemory(
- addr, section_data.GetDataStart(), section_data.GetByteSize(), error);
- if (written != section_data.GetByteSize())
-return error;
-}
- }
+ error = DoLoadInMemory(target);
+
+ if (!error.Success())
+return error;
+
if (set_pc) {
ThreadList &thread_list = process->GetThreadList();
ThreadSP curr_thread(thread_list.GetSelectedThread());
@@ -685,6 +671,32 @@
return error;
}
+Status ObjectFile::DoLoadInMemory(Target &target) {
+ SectionList *section_list = GetSectionList();
+ if (!section_list)
+return Status("No section in object file");
+
+ std::vector writeEntries;
+ // Create a list of write entries from loadable sections
+ size_t section_count = section_list->GetNumSections(0);
+ for (size_t i = 0; i < section_count; ++i) {
+Process::WriteEntry entry;
+SectionSP section_sp = section_list->GetSectionAtIndex(i);
+entry.Dest = target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
+if (entry.Dest == LLDB_INVALID_ADDRESS)
+ continue;
+// We can skip sections like bss
+if (section_sp->GetFileSize() == 0)
+ continue;
+DataExtractor section_data;
+section_sp->GetSectionData(section_data);
+entry.Contents = llvm::ArrayRef(section_data.GetDataStart(),
+ section_data.GetByteSize());
+writeEntries.push_back(entry);
+ }
+ return target.CalculateProcess()->WriteObjectFile(std::move(writeEntries));
+}
+
void ObjectFile::RelocateSection(lldb_private::Section *section)
{
}
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -144,6 +144,8 @@
size_t DoReadMemory(lldb::addr_t addr, void *buf, size_t size,
Status &error) override;
+ Status WriteObjectFile(std::vector entries) override;
+
size_t DoWriteMemory(lldb::addr_t addr, const void *buf, size_t size,
Status &error) override;
@@ -302,6 +304,11 @@
int64_t m_br
[Lldb-commits] [PATCH] D43837: Move option parsing out of the Args class
jingham accepted this revision. jingham added a comment. This revision is now accepted and ready to land. Nope. https://reviews.llvm.org/D43837 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
> On Mar 8, 2018, at 2:49 AM, Pavel Labath wrote: > > > > > On Thu, 8 Mar 2018 at 02:46, Davide Italiano wrote: > On Wed, Mar 7, 2018 at 6:39 PM, Jim Ingham wrote: > > The hashing algorithm gives different values - at least for foobár - > > between the two implementations. So if you build with an older clang, and > > test with a new lldb, the type lookup fails. > > > When I landed this patch, the two algorithms were identical, but this wasn't > always the case. The llvm's version of the algorithm used to be > nondeterministic (as in, it's result depended on the signedness of char on > your platform). This was recently fixed, and this patch was meant to make > sure they always stay in sync. > > We considered a couple of options when we noticed this discrepancy, but since > this had never really worked (llvm and lldb had always disagreed on the hash > value of strings with high bit set) and nobody noticed, we decided to just > fix the llvm implementation. The other option was to create a signedDJBHash > function, and make lldb&llvm always use that for apple accelerator tables. I > guess it's still not too late to do that... I have no idea how common the use of high bit characters in C identifiers is. I can't remember ever seeing a usage in browsing through the Darwin sources. We do have to support users who want to debug released products using older dSYM's, but if high bit identifiers are an uncommon practice, then just making sure lldb & clang & llvm-dsymutil stay in sync in the future is probably good enough. IIRC the old dsymutil could run fixups on dsym's, and so if somebody ends up being really stuck because of this, we could teach llvm-dsymutil to regenerate the apple tables in the dSYM with the new hashes. dsymutil doesn't use the apple tables from .o files, it rebuilds them, so doing this should be pretty straightforward. The harder part is likely conveying to users when it is necessary to do so... > > > This is not my case, I think? I'm building from the monorepo so clang > and lldb are supposed to be in sync (in fact, the version of clang in > my test is 7.0). > > > My best (and only) guess would be that this is because of different versions > of dsymutil (we are using the system dsymutil to build the dsym bundle), > though I'm not sure then why the test doesn't fail for me as well, as I have > the stock dsymutil that ships which XCode, which presumably still has the > broken hash function. > > Could you send me the main.o and a.out.dSYM files that are built by this test > (or at least the output of running llvm-dwarfdump -apple-types on them), so I > can compare them with mine? The interesting question is what does "foobár" > hash to (for me it's 0xba721fe1 in both files). > IIRC Davide said only the dSYM variant of the test was failing for him. If that's true then using the system dsymutil explains the difference. But I don't know why the dSYM variant isn't failing for you. Jim ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
On Thu, Mar 8, 2018 at 10:46 AM, Jim Ingham wrote: > > >> On Mar 8, 2018, at 2:49 AM, Pavel Labath wrote: >> >> >> >> >> On Thu, 8 Mar 2018 at 02:46, Davide Italiano wrote: >> On Wed, Mar 7, 2018 at 6:39 PM, Jim Ingham wrote: >> > The hashing algorithm gives different values - at least for foobár - >> > between the two implementations. So if you build with an older clang, and >> > test with a new lldb, the type lookup fails. >> > >> When I landed this patch, the two algorithms were identical, but this wasn't >> always the case. The llvm's version of the algorithm used to be >> nondeterministic (as in, it's result depended on the signedness of char on >> your platform). This was recently fixed, and this patch was meant to make >> sure they always stay in sync. >> >> We considered a couple of options when we noticed this discrepancy, but >> since this had never really worked (llvm and lldb had always disagreed on >> the hash value of strings with high bit set) and nobody noticed, we decided >> to just fix the llvm implementation. The other option was to create a >> signedDJBHash function, and make lldb&llvm always use that for apple >> accelerator tables. I guess it's still not too late to do that... > > > I have no idea how common the use of high bit characters in C identifiers is. > I can't remember ever seeing a usage in browsing through the Darwin sources. > We do have to support users who want to debug released products using older > dSYM's, but if high bit identifiers are an uncommon practice, then just > making sure lldb & clang & llvm-dsymutil stay in sync in the future is > probably good enough. IIRC the old dsymutil could run fixups on dsym's, and > so if somebody ends up being really stuck because of this, we could teach > llvm-dsymutil to regenerate the apple tables in the dSYM with the new hashes. > dsymutil doesn't use the apple tables from .o files, it rebuilds them, so > doing this should be pretty straightforward. The harder part is likely > conveying to users when it is necessary to do so... > >> >> >> This is not my case, I think? I'm building from the monorepo so clang >> and lldb are supposed to be in sync (in fact, the version of clang in >> my test is 7.0). >> >> >> My best (and only) guess would be that this is because of different versions >> of dsymutil (we are using the system dsymutil to build the dsym bundle), >> though I'm not sure then why the test doesn't fail for me as well, as I have >> the stock dsymutil that ships which XCode, which presumably still has the >> broken hash function. >> >> Could you send me the main.o and a.out.dSYM files that are built by this >> test (or at least the output of running llvm-dwarfdump -apple-types on >> them), so I can compare them with mine? The interesting question is what >> does "foobár" hash to (for me it's 0xba721fe1 in both files). >> > > IIRC Davide said only the dSYM variant of the test was failing for him. If > that's true then using the system dsymutil explains the difference. But I > don't know why the dSYM variant isn't failing for you. > > Jim > Yes, that's the reason. The tests seem to pick the system `dsymutil` instead of the one that's built `in-tree`. I'll have a chat with Jonas about this. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43512: DWZ 11/11: Fix for symlinked .build-id/**.debug files
jankratochvil updated this revision to Diff 137622.
https://reviews.llvm.org/D43512
Files:
packages/Python/lldbsuite/test/decorators.py
packages/Python/lldbsuite/test/linux/buildidsymlink/Makefile
packages/Python/lldbsuite/test/linux/buildidsymlink/TestTargetSymbolsBuildidSymlink.py
packages/Python/lldbsuite/test/linux/buildidsymlink/main.c
source/Host/common/Symbols.cpp
Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -283,6 +283,8 @@
if (llvm::sys::fs::equivalent(file_spec.GetPath(),
module_file_spec.GetPath()))
continue;
+if (FileSystem::ResolveSymbolicLink(file_spec, file_spec).Fail())
+ continue;
if (file_spec.Exists()) {
lldb_private::ModuleSpecList specs;
Index: packages/Python/lldbsuite/test/linux/buildidsymlink/main.c
===
--- /dev/null
+++ packages/Python/lldbsuite/test/linux/buildidsymlink/main.c
@@ -0,0 +1,6 @@
+struct s {
+ int i1, i2, i3, i4, i5, i6, i7, i8, i9;
+} v;
+int main() {
+ return 0;
+}
Index: packages/Python/lldbsuite/test/linux/buildidsymlink/TestTargetSymbolsBuildidSymlink.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/linux/buildidsymlink/TestTargetSymbolsBuildidSymlink.py
@@ -0,0 +1,24 @@
+""" Testing separate debug info loading for base binary with a symlink. """
+import os
+import time
+import lldb
+import sys
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestTargetSymbolsBuildidSymlink(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test # Prevent the genaration of the dwarf version of this test
+@skipUnlessPlatform(['linux'])
+@skipIf(hostoslist=["windows"])
+@skipIfRemote # llvm.org/pr36237
+@skipUnlessDWZInstalled
+def test_target_symbols_buildid_symlink(self):
+self.build(clean=True)
+exe = self.getBuildArtifact("stripped.out")
+
+lldbutil.run_to_name_breakpoint(self, "main", exe_name = exe)
Index: packages/Python/lldbsuite/test/linux/buildidsymlink/Makefile
===
--- /dev/null
+++ packages/Python/lldbsuite/test/linux/buildidsymlink/Makefile
@@ -0,0 +1,24 @@
+LEVEL = ../../make
+C_SOURCES := main.c
+LD_EXTRAS += -Wl,--build-id=sha1
+
+all: .build-id
+
+.PHONY: .build-id
+stripped.out stripped.debug stripped.debug.dwz: a.out
+ eu-strip --remove-comment -f stripped.debug -F stripped.debugx -o stripped.out $<
+ cp -p stripped.debug stripped.debug.dup
+ dwz -m stripped.debug.dwz stripped.debug stripped.debug.dup
+
+.build-id: stripped.debug
+ $(OBJCOPY) -j .note.gnu.build-id -O binary $< tmp
+ rm -rf .build-id
+ fn=`od -An -tx1 ___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r327052 - [test] Skip a test when using an out-of-tree debugserver
Author: vedantk Date: Thu Mar 8 11:46:39 2018 New Revision: 327052 URL: http://llvm.org/viewvc/llvm-project?rev=327052&view=rev Log: [test] Skip a test when using an out-of-tree debugserver The test "test_fp_special_purpose_register_read" in TestRegisters.py fails on Darwin machines configured to use an out-of-tree debugserver. The error message is: 'register read ftag' returns expected result, got 'ftag = 0x80'. This indicates that the debugserver in use is too old. This commit introduces a decorator which can be used to skip tests which rely on having a just-built debugserver. This resolves the issue: $ ./bin/llvm-dotest -p TestRegisters.py -v 1 out of 617 test suites processed - TestRegisters.py Test Methods: 7 Success: 6 Skip: 1 ... Modified: lldb/trunk/packages/Python/lldbsuite/test/decorators.py lldb/trunk/packages/Python/lldbsuite/test/dotest.py lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py lldb/trunk/packages/Python/lldbsuite/test/lldbtest_config.py lldb/trunk/test/CMakeLists.txt Modified: lldb/trunk/packages/Python/lldbsuite/test/decorators.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/decorators.py?rev=327052&r1=327051&r2=327052&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Thu Mar 8 11:46:39 2018 @@ -22,6 +22,7 @@ import use_lldb_suite import lldb from . import configuration from . import test_categories +from . import lldbtest_config from lldbsuite.test_event.event_builder import EventBuilder from lldbsuite.support import funcutils from lldbsuite.test import lldbplatform @@ -476,6 +477,11 @@ def expectedFlakeyAndroid(bugnumber=None archs), bugnumber) +def skipIfOutOfTreeDebugserver(func): +"""Decorate the item to skip tests if using an out-of-tree debugserver.""" +def is_out_of_tree_debugserver(): +return "out-of-tree debugserver" if lldbtest_config.out_of_tree_debugserver else None +return skipTestIfFn(is_out_of_tree_debugserver)(func) def skipIfRemote(func): """Decorate the item to skip tests if testing remotely.""" Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=327052&r1=327051&r2=327052&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Thu Mar 8 11:46:39 2018 @@ -307,6 +307,9 @@ def parseOptionsAndInitTestdirs(): if args.log_success: lldbtest_config.log_success = args.log_success +if args.out_of_tree_debugserver: +lldbtest_config.out_of_tree_debugserver = args.out_of_tree_debugserver + # Set SDKROOT if we are using an Apple SDK if platform_system == 'Darwin' and args.apple_sdk: os.environ['SDKROOT'] = seven.get_command_output( Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py?rev=327052&r1=327051&r2=327052&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py Thu Mar 8 11:46:39 2018 @@ -127,6 +127,11 @@ def create_parser(): metavar='server-path', help='The path to the debug server executable to use') group.add_argument( +'--out-of-tree-debugserver', +dest='out_of_tree_debugserver', +action='store_true', +help='A flag to indicate an out-of-tree debug server is being used') +group.add_argument( '-s', metavar='name', help='Specify the name of the dir created to store the session files of tests with errored or failed status. If not specified, the test driver uses the timestamp as the session dir name') Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py?rev=327052&r1=327051&r2=327052&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/register_command/TestRegisters.py Thu Mar 8 11:46:39 2018 @@ -69,6 +69,7 @@ class RegisterC
[Lldb-commits] [PATCH] D40475: DWZ 10/11: DWZ test mode
jankratochvil added a comment. In https://reviews.llvm.org/D40475#1018951, @davide wrote: > fwiw, you don't need unit tests or python tests to implement this. > If I understand the feature correctly you can probably extend `lldb-test` > (which is run as part of `check-lldb-lit`). I do not understand much yet all the testing frameworks LLDB implements. Could you suggest what you find redundant? So far I do want to run the whole testsuite also in `dwz` mode. I understand `unittests/SymbolFile/DWZ/SymbolFileDWZTests.cpp` could be written also as an extension of `tools/lldb-test`. But then I do not see why. The unit test of mine looks fine to me. https://reviews.llvm.org/D40475 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r327084 - Three little cleanups in the debugserver xcode project file.
Author: jmolenda
Date: Thu Mar 8 16:17:22 2018
New Revision: 327084
URL: http://llvm.org/viewvc/llvm-project?rev=327084&view=rev
Log:
Three little cleanups in the debugserver xcode project file.
1. Link against libpmenergy and pmsample unconditionally. It is available on
macOS 10.10 ("Yosemite") and newer. We're already linking against
libcompression
unconditionally which is only available on macOS 10.11 & newer.
2. Change a few "sdk=macosx.internal"'s to sdk=macosx.
3. Clean up a few places where libcompression was being enabled inconsistently.
Note: the -DLLDB_ENERGY define is only set when building against the
macosx.internal
SDK; it includes a header file that is not public. We link against the dylibs
unconditionally for simplicity.
Modified:
lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=327084&r1=327083&r2=327084&view=diff
==
--- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
(original)
+++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Thu Mar
8 16:17:22 2018
@@ -714,9 +714,7 @@
GCC_WARN_UNUSED_FUNCTION = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
LLDB_COMPRESSION_CFLAGS =
"-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_CFLAGS[sdk=macosx10.11]" =
"-DHAVE_LIBCOMPRESSION=1";
LLDB_COMPRESSION_LDFLAGS = "-lcompression";
- "LLDB_COMPRESSION_LDFLAGS[sdk=macosx10.11]" =
"-lcompression";
LLDB_OS_LOG_CFLAGS =
"-DLLDB_USE_OS_LOG=$(LLDB_USE_OS_LOG)";
LLDB_USE_OS_LOG = 0;
LLDB_ZLIB_CFLAGS = "-DHAVE_LIBZ=1";
@@ -758,9 +756,7 @@
GCC_WARN_UNUSED_FUNCTION = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
LLDB_COMPRESSION_CFLAGS =
"-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_CFLAGS[sdk=macosx10.11]" =
"-DHAVE_LIBCOMPRESSION=1";
LLDB_COMPRESSION_LDFLAGS = "-lcompression";
- "LLDB_COMPRESSION_LDFLAGS[sdk=macosx10.11]" =
"-lcompression";
LLDB_OS_LOG_CFLAGS =
"-DLLDB_USE_OS_LOG=$(LLDB_USE_OS_LOG)";
LLDB_USE_OS_LOG = 0;
LLDB_ZLIB_CFLAGS = "-DHAVE_LIBZ=1";
@@ -800,9 +796,7 @@
GCC_WARN_UNUSED_FUNCTION = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
LLDB_COMPRESSION_CFLAGS =
"-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_CFLAGS[sdk=macosx10.11]" =
"-DHAVE_LIBCOMPRESSION=1";
LLDB_COMPRESSION_LDFLAGS = "-lcompression";
- "LLDB_COMPRESSION_LDFLAGS[sdk=macosx10.11]" =
"-lcompression";
LLDB_OS_LOG_CFLAGS =
"-DLLDB_USE_OS_LOG=$(LLDB_USE_OS_LOG)";
LLDB_USE_OS_LOG = 1;
LLDB_ZLIB_CFLAGS = "-DHAVE_LIBZ=1";
@@ -839,22 +833,12 @@
HEADER_SEARCH_PATHS =
/System/Library/Frameworks/System.framework/PrivateHeaders;
INSTALL_PATH = /usr/bin;
"INSTALL_PATH[sdk=iphoneos*]" =
/Developer/usr/bin/;
- LLDB_COMPRESSION_CFLAGS = "";
- "LLDB_COMPRESSION_CFLAGS[sdk=appletvos*]" =
"-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_CFLAGS[sdk=iphoneos*]" =
"-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_CFLAGS[sdk=macosx10.11]" =
"-DHAVE_LIBCOMPRESSION=1";
-
"LLDB_COMPRESSION_CFLAGS[sdk=macosx10.11internal]" = "-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_CFLAGS[sdk=watchos*]" =
"-DHAVE_LIBCOMPRESSION=1";
- LLDB_COMPRESSION_LDFLAGS = "";
- "LLDB_COMPRESSION_LDFLAGS[sdk=appletvos*]" =
"-weak-lcompression";
- "LLDB_COMPRESSION_LDFLAGS[sdk=iphoneos*]" =
"-weak-lcompression";
- "LLDB_COMPRESSION_LDFLAGS[sdk=macosx10.11]" =
"-weak-lcompression";
-
"LLDB_COMPRESSION_LDFLAGS[sdk=macosx10.11internal]" = "-weak-lcompression";
- "LLDB_COMPRESSION_LDFLAGS[sdk=watchos*]" =
"-weak-lcompression";
+ LLDB_COMPRESSION_CF
[Lldb-commits] [lldb] r327085 - Fixed two more sdk inconsistencies with the pmenergy stuff.
Author: jmolenda Date: Thu Mar 8 16:23:29 2018 New Revision: 327085 URL: http://llvm.org/viewvc/llvm-project?rev=327085&view=rev Log: Fixed two more sdk inconsistencies with the pmenergy stuff. Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=327085&r1=327084&r2=327085&view=diff == --- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj (original) +++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Thu Mar 8 16:23:29 2018 @@ -837,9 +837,8 @@ LLDB_COMPRESSION_LDFLAGS = "-lcompression"; LLDB_DEBUGSERVER = 1; LLDB_ENERGY_CFLAGS = ""; - "LLDB_ENERGY_CFLAGS[sdk=macosx*]" = "-DLLDB_ENERGY"; + "LLDB_ENERGY_CFLAGS[sdk=macosx.internal]" = "-DLLDB_ENERGY"; LLDB_ENERGY_LFLAGS = "-lpmenergy -lpmsample"; - "LLDB_ENERGY_LFLAGS[sdk=macosx*]" = "-lpmenergy -lpmsample"; LLDB_ZLIB_CFLAGS = "-DHAVE_LIBZ=1"; LLDB_ZLIB_LDFLAGS = "-lz"; OTHER_CFLAGS = ( @@ -1325,9 +1324,8 @@ "INSTALL_PATH[sdk=iphoneos*]" = /usr/local/bin; LLDB_DEBUGSERVER = 1; LLDB_ENERGY_CFLAGS = ""; - "LLDB_ENERGY_CFLAGS[sdk=macosx*]" = "-DLLDB_ENERGY"; - LLDB_ENERGY_LFLAGS = ""; - "LLDB_ENERGY_LFLAGS[sdk=macosx*]" = "-lpmenergy -lpmsample"; + "LLDB_ENERGY_CFLAGS[sdk=macosx.internal]" = "-DLLDB_ENERGY"; + LLDB_ENERGY_LFLAGS = "-lpmenergy -lpmsample"; OTHER_CFLAGS = ( "-Wparentheses", "$(LLDB_ENERGY_CFLAGS)", ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r327087 - Remove the explicit dependency on libpmenergy and libpmsample.
Author: jmolenda
Date: Thu Mar 8 16:28:51 2018
New Revision: 327087
URL: http://llvm.org/viewvc/llvm-project?rev=327087&view=rev
Log:
Remove the explicit dependency on libpmenergy and libpmsample.
Modified:
lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=327087&r1=327086&r2=327087&view=diff
==
--- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
(original)
+++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Thu Mar
8 16:28:51 2018
@@ -221,8 +221,6 @@
AF67AC000D34604D0022D128 /* PseudoTerminal.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path =
PseudoTerminal.h; sourceTree = ""; };
AFEC3363194A8B0B00FF05C6 /* Genealogy.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = Genealogy.cpp; sourceTree = ""; };
D6631CA81E848FE9006A7B11 /* SocketAddress.cpp */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.cpp.cpp; name =
SocketAddress.cpp; path = ../../source/Host/common/SocketAddress.cpp;
sourceTree = ""; };
- ED128B7918E1F163003F6A7B /* libpmenergy.dylib */ = {isa =
PBXFileReference; lastKnownFileType = "compiled.mach-o.dylib"; name =
libpmenergy.dylib; path = usr/lib/libpmenergy.dylib; sourceTree = SDKROOT; };
- ED128B7A18E1F163003F6A7B /* libpmsample.dylib */ = {isa =
PBXFileReference; lastKnownFileType = "compiled.mach-o.dylib"; name =
libpmsample.dylib; path = usr/lib/libpmsample.dylib; sourceTree = SDKROOT; };
EF88788B0D9C7558001831DA /* com.apple.debugserver.applist.plist
*/ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
text.plist.xml; path = com.apple.debugserver.applist.plist; sourceTree =
""; };
EF88789F0D9C797C001831DA /* RNBServices.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path =
RNBServices.h; sourceTree = ""; };
EF8878A00D9C797C001831DA /* RNBServices.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = RNBServices.cpp; sourceTree = ""; };
@@ -377,8 +375,6 @@
26ACA3330D3E94F200A2120B /* Framework */ = {
isa = PBXGroup;
children = (
- ED128B7918E1F163003F6A7B /* libpmenergy.dylib
*/,
- ED128B7A18E1F163003F6A7B /* libpmsample.dylib
*/,
26ACA3340D3E956300A2120B /*
CoreFoundation.framework */,
);
name = Framework;
@@ -1115,8 +,8 @@
GCC_WARN_UNUSED_FUNCTION = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
INSTALL_PATH = /usr/local/bin;
- "LLDB_COMPRESSION_CFLAGS" =
"-DHAVE_LIBCOMPRESSION=1";
- "LLDB_COMPRESSION_LDFLAGS" = "-lcompression";
+ LLDB_COMPRESSION_CFLAGS =
"-DHAVE_LIBCOMPRESSION=1";
+ LLDB_COMPRESSION_LDFLAGS = "-lcompression";
LLDB_DEBUGSERVER = 1;
LLDB_ENERGY_CFLAGS = "";
"LLDB_ENERGY_CFLAGS[sdk=macosx.internal]" =
"-DLLDB_ENERGY";
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r327088 - Remove unneeded per-arch sdk specifications from debugserver xcode project file.
Author: jmolenda Date: Thu Mar 8 16:32:56 2018 New Revision: 327088 URL: http://llvm.org/viewvc/llvm-project?rev=327088&view=rev Log: Remove unneeded per-arch sdk specifications from debugserver xcode project file. Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=327088&r1=327087&r2=327088&view=diff == --- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj (original) +++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Thu Mar 8 16:32:56 2018 @@ -884,9 +884,6 @@ OTHER_MIGFLAGS = "-I$(DERIVED_FILE_DIR)"; PRODUCT_NAME = debugserver; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; SKIP_INSTALL = YES; "SKIP_INSTALL[sdk=iphoneos*]" = NO; STRIP_INSTALLED_PRODUCT = YES; @@ -975,9 +972,6 @@ "PROVISIONING_PROFILE[sdk=iphoneos*]" = ""; "PROVISIONING_PROFILE[sdk=macosx*]" = ""; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; SKIP_INSTALL = YES; USER_HEADER_SEARCH_PATHS = "./source ../../source $(DERIVED_SOURCES_DIR) ../../include"; ZERO_LINK = NO; @@ -1063,9 +1057,6 @@ "PROVISIONING_PROFILE[sdk=iphoneos*]" = ""; "PROVISIONING_PROFILE[sdk=macosx*]" = ""; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; SKIP_INSTALL = YES; USER_HEADER_SEARCH_PATHS = "./source ../../source $(DERIVED_SOURCES_DIR) ../../include"; ZERO_LINK = NO; @@ -1145,9 +1136,6 @@ "PROVISIONING_PROFILE[sdk=iphoneos*]" = ""; "PROVISIONING_PROFILE[sdk=macosx*]" = ""; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; SKIP_INSTALL = YES; STRIP_INSTALLED_PRODUCT = NO; USER_HEADER_SEARCH_PATHS = "./source ../../source $(DERIVED_SOURCES_DIR) ../../include"; @@ -1215,9 +1203,6 @@ "PROVISIONING_PROFILE[sdk=iphoneos*]" = ""; "PROVISIONING_PROFILE[sdk=macosx*]" = ""; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; SKIP_INSTALL = YES; USER_HEADER_SEARCH_PATHS = "./source ../../source $(DERIVED_SOURCES_DIR) ../../include"; ZERO_LINK = NO; @@ -1285,9 +1270,6 @@ "PROVISIONING_PROFILE[sdk=iphoneos*]" = ""; "PROVISIONING_PROFILE[sdk=macosx*]" = ""; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; SKIP_INSTALL = YES; USER_HEADER_SEARCH_PATHS = "./source ../../source $(DERIVED_SOURCES_DIR) ../../include"; ZERO_LINK = NO; @@ -1393,9 +1375,6 @@ LLDB_USE_OS_LOG = 0; ONLY_ACTIVE_ARCH = YES; SDKROOT = macosx; - "SDKROOT[arch=i386]" = macosx; - "SDKROOT[arch=x86_64]" = macosx; - "SDKROOT[arch=x86_64h]" = macosx; STRIP_INSTALLED_PRODUCT
[Lldb-commits] [lldb] r327089 - [test] Skip a test which sporadically fails in its dsym variant
Author: vedantk Date: Thu Mar 8 16:34:43 2018 New Revision: 327089 URL: http://llvm.org/viewvc/llvm-project?rev=327089&view=rev Log: [test] Skip a test which sporadically fails in its dsym variant There is a mailing list discussion re: r325927 about why this test fails in the dsym variant. I've marked it skipped for now, until the issue is resolved. Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py?rev=327089&r1=327088&r2=327089&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py Thu Mar 8 16:34:43 2018 @@ -2,12 +2,14 @@ import lldb from lldbsuite.test.lldbtest import * import lldbsuite.test.lldbutil as lldbutil +from lldbsuite.test.decorators import * class TestUnicodeSymbols(TestBase): mydir = TestBase.compute_mydir(__file__) +@skipIf(debug_info=["dsym"]) def test_union_members(self): self.build() spec = lldb.SBModuleSpec() ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
I've gone ahead and skipped this test for the dsym variant until this is resolved. r327089. vedant > On Mar 8, 2018, at 10:49 AM, Davide Italiano via lldb-commits > wrote: > > On Thu, Mar 8, 2018 at 10:46 AM, Jim Ingham wrote: >> >> >>> On Mar 8, 2018, at 2:49 AM, Pavel Labath wrote: >>> >>> >>> >>> >>> On Thu, 8 Mar 2018 at 02:46, Davide Italiano wrote: >>> On Wed, Mar 7, 2018 at 6:39 PM, Jim Ingham wrote: The hashing algorithm gives different values - at least for foobár - between the two implementations. So if you build with an older clang, and test with a new lldb, the type lookup fails. >>> When I landed this patch, the two algorithms were identical, but this >>> wasn't always the case. The llvm's version of the algorithm used to be >>> nondeterministic (as in, it's result depended on the signedness of char on >>> your platform). This was recently fixed, and this patch was meant to make >>> sure they always stay in sync. >>> >>> We considered a couple of options when we noticed this discrepancy, but >>> since this had never really worked (llvm and lldb had always disagreed on >>> the hash value of strings with high bit set) and nobody noticed, we decided >>> to just fix the llvm implementation. The other option was to create a >>> signedDJBHash function, and make lldb&llvm always use that for apple >>> accelerator tables. I guess it's still not too late to do that... >> >> >> I have no idea how common the use of high bit characters in C identifiers >> is. I can't remember ever seeing a usage in browsing through the Darwin >> sources. We do have to support users who want to debug released products >> using older dSYM's, but if high bit identifiers are an uncommon practice, >> then just making sure lldb & clang & llvm-dsymutil stay in sync in the >> future is probably good enough. IIRC the old dsymutil could run fixups on >> dsym's, and so if somebody ends up being really stuck because of this, we >> could teach llvm-dsymutil to regenerate the apple tables in the dSYM with >> the new hashes. dsymutil doesn't use the apple tables from .o files, it >> rebuilds them, so doing this should be pretty straightforward. The harder >> part is likely conveying to users when it is necessary to do so... >> >>> >>> >>> This is not my case, I think? I'm building from the monorepo so clang >>> and lldb are supposed to be in sync (in fact, the version of clang in >>> my test is 7.0). >>> >>> >>> My best (and only) guess would be that this is because of different >>> versions of dsymutil (we are using the system dsymutil to build the dsym >>> bundle), though I'm not sure then why the test doesn't fail for me as well, >>> as I have the stock dsymutil that ships which XCode, which presumably still >>> has the broken hash function. >>> >>> Could you send me the main.o and a.out.dSYM files that are built by this >>> test (or at least the output of running llvm-dwarfdump -apple-types on >>> them), so I can compare them with mine? The interesting question is what >>> does "foobár" hash to (for me it's 0xba721fe1 in both files). >>> >> >> IIRC Davide said only the dSYM variant of the test was failing for him. If >> that's true then using the system dsymutil explains the difference. But I >> don't know why the dSYM variant isn't failing for you. >> >> Jim >> > > Yes, that's the reason. The tests seem to pick the system `dsymutil` > instead of the one that's built `in-tree`. I'll have a chat with Jonas > about this. > ___ > 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] r327095 - More cleanups of debugserver project file and the libpmenergy/libpmsample
Author: jmolenda
Date: Thu Mar 8 17:37:37 2018
New Revision: 327095
URL: http://llvm.org/viewvc/llvm-project?rev=327095&view=rev
Log:
More cleanups of debugserver project file and the libpmenergy/libpmsample
stuff. Activate it when an internal SDK is selected. Update the name of
the LDFLAGS to match the rest of the settings. Update the default arch for
ios builds.
Modified:
lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=327095&r1=327094&r2=327095&view=diff
==
--- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
(original)
+++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Thu Mar
8 17:37:37 2018
@@ -684,10 +684,7 @@
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
- "ARCHS[sdk=iphoneos*]" = (
- arm64,
- armv7,
- );
+ "ARCHS[sdk=iphoneos*]" = arm64;
"ARCHS[sdk=macosx*]" =
"$(ARCHS_STANDARD_64_BIT)";
CLANG_WARN_BOOL_CONVERSION = YES;
CLANG_WARN_CONSTANT_CONVERSION = YES;
@@ -727,10 +724,7 @@
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
- "ARCHS[sdk=iphoneos*]" = (
- armv7,
- armv7s,
- );
+ "ARCHS[sdk=iphoneos*]" = arm64;
"ARCHS[sdk=macosx*]" =
"$(ARCHS_STANDARD_64_BIT)";
CLANG_WARN_BOOL_CONVERSION = YES;
CLANG_WARN_CONSTANT_CONVERSION = YES;
@@ -753,12 +747,61 @@
GCC_WARN_UNUSED_VARIABLE = YES;
LLDB_COMPRESSION_CFLAGS =
"-DHAVE_LIBCOMPRESSION=1";
LLDB_COMPRESSION_LDFLAGS = "-lcompression";
+ LLDB_ENERGY_CFLAGS = "";
+ "LLDB_ENERGY_CFLAGS[sdk=*internal]" =
"-DLLDB_ENERGY";
+ LLDB_ENERGY_LDFLAGS = "-lpmenergy -lpmsample";
LLDB_OS_LOG_CFLAGS =
"-DLLDB_USE_OS_LOG=$(LLDB_USE_OS_LOG)";
LLDB_USE_OS_LOG = 0;
LLDB_ZLIB_CFLAGS = "-DHAVE_LIBZ=1";
LLDB_ZLIB_LDFLAGS = "-lz";
ONLY_ACTIVE_ARCH = YES;
- OTHER_CFLAGS = "";
+ OTHER_CFLAGS = (
+ "-Wparentheses",
+ "$(LLDB_ENERGY_CFLAGS)",
+ "-DDT_VARIANT_$(DT_VARIANT)",
+ "$(LLDB_ENERGY_CFLAGS)",
+ "$(LLDB_COMPRESSION_CFLAGS)",
+ "$(LLDB_ZLIB_CFLAGS)",
+ "$(LLDB_OS_LOG_CFLAGS)",
+ );
+ "OTHER_CFLAGS[sdk=iphoneos*][arch=*]" = (
+ "-Wparentheses",
+ "-DWITH_LOCKDOWN",
+ "-DWITH_FBS",
+ "-DWITH_BKS",
+ "-DOS_OBJECT_USE_OBJC=0",
+ "$(LLDB_ENERGY_CFLAGS)",
+ "$(LLDB_COMPRESSION_CFLAGS)",
+ "$(LLDB_ZLIB_CFLAGS)",
+ "$(LLDB_OS_LOG_CFLAGS)",
+ "-isystem",
+
"$(SDKROOT)/System/Library/Frameworks/System.framework/PrivateHeaders",
+ );
+ "OTHER_CPLUSPLUSFLAGS[sdk=iphoneos*][arch=*]" =
"$(OTHER_CFLAGS)";
+ OTHER_LDFLAGS = "";
+ "OTHER_LDFLAGS[sdk=iphoneos*][arch=*]" = (
+ "-framework",
+ SpringBoardServices,
+ "-framework",
+ BackBoardServices,
+ "-llockdown",
+
[Lldb-commits] [lldb] r327097 - I added CFLAGS etc to one part of the project file I should not have.
Author: jmolenda Date: Thu Mar 8 17:43:18 2018 New Revision: 327097 URL: http://llvm.org/viewvc/llvm-project?rev=327097&view=rev Log: I added CFLAGS etc to one part of the project file I should not have. Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=327097&r1=327096&r2=327097&view=diff == --- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj (original) +++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Thu Mar 8 17:43:18 2018 @@ -747,61 +747,13 @@ GCC_WARN_UNUSED_VARIABLE = YES; LLDB_COMPRESSION_CFLAGS = "-DHAVE_LIBCOMPRESSION=1"; LLDB_COMPRESSION_LDFLAGS = "-lcompression"; - LLDB_ENERGY_CFLAGS = ""; - "LLDB_ENERGY_CFLAGS[sdk=*internal]" = "-DLLDB_ENERGY"; LLDB_ENERGY_LDFLAGS = "-lpmenergy -lpmsample"; LLDB_OS_LOG_CFLAGS = "-DLLDB_USE_OS_LOG=$(LLDB_USE_OS_LOG)"; LLDB_USE_OS_LOG = 0; LLDB_ZLIB_CFLAGS = "-DHAVE_LIBZ=1"; LLDB_ZLIB_LDFLAGS = "-lz"; ONLY_ACTIVE_ARCH = YES; - OTHER_CFLAGS = ( - "-Wparentheses", - "$(LLDB_ENERGY_CFLAGS)", - "-DDT_VARIANT_$(DT_VARIANT)", - "$(LLDB_ENERGY_CFLAGS)", - "$(LLDB_COMPRESSION_CFLAGS)", - "$(LLDB_ZLIB_CFLAGS)", - "$(LLDB_OS_LOG_CFLAGS)", - ); - "OTHER_CFLAGS[sdk=iphoneos*][arch=*]" = ( - "-Wparentheses", - "-DWITH_LOCKDOWN", - "-DWITH_FBS", - "-DWITH_BKS", - "-DOS_OBJECT_USE_OBJC=0", - "$(LLDB_ENERGY_CFLAGS)", - "$(LLDB_COMPRESSION_CFLAGS)", - "$(LLDB_ZLIB_CFLAGS)", - "$(LLDB_OS_LOG_CFLAGS)", - "-isystem", - "$(SDKROOT)/System/Library/Frameworks/System.framework/PrivateHeaders", - ); - "OTHER_CPLUSPLUSFLAGS[sdk=iphoneos*][arch=*]" = "$(OTHER_CFLAGS)"; - OTHER_LDFLAGS = ""; - "OTHER_LDFLAGS[sdk=iphoneos*][arch=*]" = ( - "-framework", - SpringBoardServices, - "-framework", - BackBoardServices, - "-llockdown", - "-framework", - FrontBoardServices, - "-framework", - MobileCoreServices, - "$(LLDB_ENERGY_LDFLAGS)", - "$(LLDB_COMPRESSION_LDFLAGS)", - "$(LLDB_ZLIB_LDFLAGS)", - ); - "OTHER_LDFLAGS[sdk=macosx*]" = ( - "-sectcreate", - __TEXT, - __info_plist, - "$(PROJECT_DIR)/resources/lldb-debugserver-Info.plist", - "$(LLDB_ENERGY_LDFLAGS)", - "$(LLDB_COMPRESSION_LDFLAGS)", - "$(LLDB_ZLIB_LDFLAGS)", - ); + OTHER_CFLAGS = ""; STRIPFLAGS = "-x"; STRIP_STYLE = debugging; VERSIONING_SYSTEM = "apple-generic"; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
