[Lldb-commits] [lldb] r276220 - Fix an issue where LLDB would detect an empty shared cache - which is legitimate albeit suboptimal - and warn about being unable to fetch ObjC class information, even t
Author: enrico
Date: Wed Jul 20 19:13:40 2016
New Revision: 276220
URL: http://llvm.org/viewvc/llvm-project?rev=276220=rev
Log:
Fix an issue where LLDB would detect an empty shared cache - which is
legitimate albeit suboptimal - and warn about being unable to fetch ObjC class
information, even though class data was actually properly loaded from the
dynamic hashmap
Only ever warn about missing ObjC runtime class data if one either can't run
the expressions to obtain such data, or the total count of classes is below a
threshold that makes things sound really suspicious
Fixes rdar://27438500
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp?rev=276220=276219=276220=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
Wed Jul 20 19:13:40 2016
@@ -1350,13 +1350,15 @@ AppleObjCRuntimeV2::GetISAHashTablePoint
return m_isa_hash_table_ptr;
}
-bool
+AppleObjCRuntimeV2::DescriptorMapUpdateResult
AppleObjCRuntimeV2::UpdateISAToDescriptorMapDynamic(RemoteNXMapTable
_table)
{
Process *process = GetProcess();
if (process == NULL)
-return false;
+return DescriptorMapUpdateResult::Fail();
+
+uint32_t num_class_infos = 0;
Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));
@@ -1365,13 +1367,13 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
ThreadSP thread_sp =
process->GetThreadList().GetExpressionExecutionThread();
if (!thread_sp)
-return false;
+return DescriptorMapUpdateResult::Fail();
thread_sp->CalculateExecutionContext(exe_ctx);
ClangASTContext *ast = process->GetTarget().GetScratchClangASTContext();
if (!ast)
-return false;
+return DescriptorMapUpdateResult::Fail();
Address function_address;
@@ -1387,7 +1389,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
{
if (log)
log->Printf ("No dynamic classes found in
gdb_objc_realized_classes.");
-return false;
+return DescriptorMapUpdateResult::Fail();
}
// Make some types for our arguments
@@ -1425,7 +1427,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
}
}
if (!m_get_class_info_code.get())
-return false;
+return DescriptorMapUpdateResult::Fail();
// Next make the runner function for our implementation utility
function.
Value value;
@@ -1448,7 +1450,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
{
if (log)
log->Printf("Failed to make function caller for implementation
lookup: %s.", error.AsCString());
-return false;
+return DescriptorMapUpdateResult::Fail();
}
}
else
@@ -1462,7 +1464,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
diagnostics.Dump(log);
}
-return false;
+return DescriptorMapUpdateResult::Fail();
}
arguments = get_class_info_function->GetArgumentValues();
}
@@ -1476,7 +1478,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
err);
if (class_infos_addr == LLDB_INVALID_ADDRESS)
-return false;
+return DescriptorMapUpdateResult::Fail();
std::lock_guard guard(m_get_class_info_args_mutex);
@@ -1516,7 +1518,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
if (results == eExpressionCompleted)
{
// The result is the number of ClassInfo structures that were
filled in
-uint32_t num_class_infos = return_value.GetScalar().ULong();
+num_class_infos = return_value.GetScalar().ULong();
if (log)
log->Printf("Discovered %u ObjC classes\n",num_class_infos);
if (num_class_infos > 0)
@@ -1555,7 +1557,7 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
// Deallocate the memory we allocated for the ClassInfo array
process->DeallocateMemory(class_infos_addr);
-return success;
+return DescriptorMapUpdateResult(success, num_class_infos);
}
uint32_t
@@ -1636,6 +1638,8 @@ AppleObjCRuntimeV2::UpdateISAToDescripto
Error err;
+uint32_t num_class_infos = 0;
+
const lldb::addr_t objc_opt_ptr = GetSharedCacheReadOnlyAddress();
if (objc_opt_ptr == LLDB_INVALID_ADDRESS)
@@ -1770,7 +1774,7 @@
[Lldb-commits] [lldb] r276166 - Fix typo in test runner
Author: fjricci
Date: Wed Jul 20 14:37:31 2016
New Revision: 276166
URL: http://llvm.org/viewvc/llvm-project?rev=276166=rev
Log:
Fix typo in test runner
Modified:
lldb/trunk/packages/Python/lldbsuite/test/decorators.py
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=276166=276165=276166=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Wed Jul 20 14:37:31
2016
@@ -486,7 +486,7 @@ def skipUnlessPlatform(oslist):
# This decorator cannot be ported to `skipIf` yet because it is used on
entire
# classes, which `skipIf` explicitly forbids.
return unittest2.skipUnless(lldbplatformutil.getPlatform() in oslist,
-"requires on of %s" % (", ".join(oslist)))
+"requires one of %s" % (", ".join(oslist)))
def skipIfTargetAndroid(api_levels=None, archs=None):
"""Decorator to skip tests when the target is Android.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildmaster restart in few minutes
Hello everyone, LLVM buildmaster will be restarted in few minutes. Thank you for understanding. Thanks Galina ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r276132 - If x/i is followed by x/g, the format should be reset to 'x'.
Author: jingham
Date: Wed Jul 20 10:41:12 2016
New Revision: 276132
URL: http://llvm.org/viewvc/llvm-project?rev=276132=rev
Log:
If x/i is followed by x/g, the format should be reset to 'x'.
Otherwise, you have to say "x/gx" to what you obviously intended to
happen to happen.
Modified:
lldb/trunk/source/Interpreter/OptionGroupFormat.cpp
Modified: lldb/trunk/source/Interpreter/OptionGroupFormat.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionGroupFormat.cpp?rev=276132=276131=276132=diff
==
--- lldb/trunk/source/Interpreter/OptionGroupFormat.cpp (original)
+++ lldb/trunk/source/Interpreter/OptionGroupFormat.cpp Wed Jul 20 10:41:12 2016
@@ -230,10 +230,28 @@ OptionGroupFormat::ParserGDBFormatLetter
case 's': format = eFormatCString; m_prev_gdb_format =
format_letter; return true;
case 'T': format = eFormatOSType; m_prev_gdb_format =
format_letter; return true;
case 'A': format = eFormatHexFloat; m_prev_gdb_format =
format_letter; return true;
-case 'b': byte_size = 1;m_prev_gdb_size =
format_letter; return true;
-case 'h': byte_size = 2;m_prev_gdb_size =
format_letter; return true;
-case 'w': byte_size = 4;m_prev_gdb_size =
format_letter; return true;
-case 'g': byte_size = 8;m_prev_gdb_size =
format_letter; return true;
+
+// Size isn't used for printing instructions, so if a size is
specified, and the previous format was
+// 'i', then we should reset it to the default ('x'). Otherwise we'll
continue to print as instructions,
+// which isn't expected.
+case 'b':
+byte_size = 1;
+LLVM_FALLTHROUGH;
+case 'h':
+byte_size = 2;
+LLVM_FALLTHROUGH;
+case 'w':
+byte_size = 4;
+LLVM_FALLTHROUGH;
+case 'g':
+byte_size = 8;
+
+m_prev_gdb_size = format_letter;
+if (m_prev_gdb_format == 'i')
+m_prev_gdb_format = 'x';
+return true;
+
+break;
default: break;
}
return false;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21328: [lldb] Fixed incorrect endianness when evaluating certain expressions
cameron314 added a comment. @spyffe, do you have a minute today? https://reviews.llvm.org/D21328 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20357: [LLDB][MIPS] Fix FPU Size Based on Dynamic FR
nitesh.jain marked 8 inline comments as done. nitesh.jain added a comment. https://reviews.llvm.org/D20357 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
jlebar added a comment. Hi, Renato. Just to explain why I'm going to go forward with this RFC about a monolithic repository: From speaking with some top contributors on IRC, I have heard that they feel that the discussion of whether to move to git has been conflated with the discussion of how the git repository should be set up. So there is a sizable set of important individuals who don't feel that this question has been considered sufficiently. I would love not to alienate you by asking this question, but I understand if I already have. If so, I sincerely apologize. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20357: [LLDB][MIPS] Fix FPU Size Based on Dynamic FR
nitesh.jain updated this revision to Diff 64693.
nitesh.jain added a comment.
Removed dynamic_size_dwarf_len field from RegisterInfo struct.
https://reviews.llvm.org/D20357
Files:
include/lldb/Host/common/NativeRegisterContext.h
include/lldb/Host/common/NativeRegisterContextRegisterInfo.h
include/lldb/Target/RegisterContext.h
include/lldb/lldb-private-types.h
source/Host/common/NativeRegisterContext.cpp
source/Host/common/NativeRegisterContextRegisterInfo.cpp
source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
source/Plugins/Process/Utility/DynamicRegisterInfo.h
source/Plugins/Process/Utility/RegisterContextLinux_mips.cpp
source/Plugins/Process/Utility/RegisterContextLinux_mips.h
source/Plugins/Process/Utility/RegisterContextLinux_mips64.cpp
source/Plugins/Process/Utility/RegisterContextLinux_mips64.h
source/Plugins/Process/Utility/RegisterInfoInterface.h
source/Plugins/Process/Utility/RegisterInfos_mips.h
source/Plugins/Process/Utility/RegisterInfos_mips64.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Target/RegisterContext.cpp
Index: source/Target/RegisterContext.cpp
===
--- source/Target/RegisterContext.cpp
+++ source/Target/RegisterContext.cpp
@@ -21,7 +21,9 @@
#include "lldb/Target/Process.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/Target.h"
-
+#include "lldb/Core/Module.h"
+#include "lldb/Expression/DWARFExpression.h"
+#include "lldb/Core/Value.h"
using namespace lldb;
using namespace lldb_private;
@@ -76,6 +78,46 @@
return nullptr;
}
+uint32_t
+RegisterContext::UpdateDynamicRegisterSize (const lldb_private::ArchSpec ,
+RegisterInfo* reg_info,
+size_t opcode_len)
+{
+ExecutionContext exe_ctx (CalculateThread());
+
+// In MIPS, the floating point registers size is depends on FR bit of SR register.
+// if SR.FR == 1 then all floating point registers are 64 bits.
+// else they are all 32 bits.
+
+int expr_result;
+uint32_t addr_size = arch.GetAddressByteSize ();
+const uint8_t* opcode_ptr = reg_info->dynamic_size_dwarf_expr_bytes;
+
+DataExtractor dwarf_data (opcode_ptr, opcode_len,
+ arch.GetByteOrder (), addr_size);
+ModuleSP opcode_ctx;
+DWARFExpression dwarf_expr (opcode_ctx, dwarf_data, nullptr, 0, opcode_len);
+Value result;
+Error error;
+const lldb::offset_t offset = 0;
+if(dwarf_expr.Evaluate (_ctx, nullptr, nullptr, this, opcode_ctx, dwarf_data, nullptr,
+offset, opcode_len, eRegisterKindDWARF, nullptr, nullptr, result, ))
+{
+expr_result = result.GetScalar().SInt(-1);
+switch (expr_result)
+{
+case 0: return 4;
+case 1: return 8;
+default: return reg_info->byte_size;
+}
+}
+else
+{
+printf("Error executing DwarfExpression::Evaluate %s\n", error.AsCString());
+return reg_info->byte_size;
+}
+}
+
const RegisterInfo *
RegisterContext::GetRegisterInfo (lldb::RegisterKind kind, uint32_t num)
{
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -539,6 +539,8 @@
ConstString set_name;
std::vector value_regs;
std::vector invalidate_regs;
+uint8_t *dwarf_opcode_bytes = NULL;
+uint32_t dwarf_expr_bytes_len;
RegisterInfo reg_info = { NULL, // Name
NULL, // Alt name
0,// byte size
@@ -553,6 +555,7 @@
reg_num // native register number
},
NULL,
+NULL,
NULL
};
@@ -638,6 +641,25 @@
{
SplitCommaSeparatedRegisterNumberString(value, invalidate_regs, 16);
}
+else if (name.compare("dynamic_size_dwarf_expr_bytes") == 0)
+{
+ dwarf_expr_bytes_len = value.length () / 2;
+ assert(dwarf_expr_bytes_len > 0);
+ dwarf_opcode_bytes = new uint8_t[dwarf_expr_bytes_len];
+ StringExtractor name_extractor;
+
+ if (dwarf_opcode_bytes)
+ {
+ // Swap "value" over into "name_extractor"
+
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added a comment. In https://reviews.llvm.org/D22463#489483, @jlebar wrote: > Again, we can make this work with submodules, but it's a giant pain, see my > earlier comment. (...) > I've read as many of these as I can find in the past few hours, and every > argument I have found is, in my evaluation, very likely overblown or > incorrect. We've heard both sides making equal claims. People work differently. > The critical point is that it's trivial to use sparse checkouts to make the > monolithic repository behave identically to separate repos. But it is > impossible, as far as I'm aware, to make separate repos behave like a > monolithic repository. So the monolithic repository is strictly more > powerful. LLVM is *not* a single project, but a large selection of smaller ones that *are* used independently by the *majority* of users. It may tax you more than others, but it will tax the majority less than today's solution. This is not about finding the best possible way for everyone, since that's clearly impossible. This is about finding the least horrible solution for the majority. > The e-mail you sent out two days ago said two weeks. Can you give me a bit > more than three days? Moving to Git has been in discussion for at least 2 years. This time round, my first email with a concrete proposal to migrate was 2nd June. We had so far 320+ emails about the subject since, and the overwhelming majority is in favour to move to Git and a large part is *content* with sub-modules. Counter proposals were presented (including a monolithic repository) and were all shot down by the community (not me). This is not the time to be second guessing ourselves. I'll be finishing this proposal this week and asking the foundation to put up a survey as soon as possible. > But. I would ask you to please give me a few days to work with the community > to dig in to this specific question. If I am right, it will be a boon for > all of us every time we type a command that starts with "git". And if I'm > wrong, I'll buy you a well-deserved beer or three, and we'll forget it and > move on. A monolithic repository was proposed and discredited by the community. I can't vouch for it myself (in the interest of progress), but we *will* allow people to add comments on the survey. If there is a sound opposition to sub-modules in the survey, and a solid proposal to use a monolithic repo instead, we'll go to the next cycle, in which case, I'll politely step down and let other people in charge (whomever wants it). All in all, we (for any definition of "we") are not going to force anyone to do anything they don't want. But as a community, we really should be thinking about the whole process, not just a single use case. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added a comment. You will not be required to use submodules at all, as we'll all use the individual projects, like we have always been. I don't understand why people keep going back to it. Having a single repository was part of the original proposal for years, and every time it was shot down as impractical. Indeed, this is not the place for such discussion, but unless you can finish the discussion thus week, I suggest you make you point clear in the survey instead of delaying the process. I'm not pushing for *my* solution. Thus *has* been discussed already to exhaustion. The current agreement was that we'd do a survey on the proposal, and that's what we need to do. Anything else will just send us back to square one and I seriously don't have the stamina to keep going round in circles. Ie. Please, try to be considerate. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
