Re: [Lldb-commits] [PATCH] D16853: Use BKPT instead of UDF for arm/thumb breakpoints
omjavaid added a comment. GDB doesnt use bkpt instruction for user debugging for the reason that it interferes with jtag debug probes. I am not sure if LLDB will be ever used with a jtag probe in near future but still a jtag prob might be connected to the same hardware which is using LLDB to debug a user space application. heres a discussion which happened some years back on similar issues: https://sourceware.org/ml/gdb-patches/2010-01/msg00624.html http://www.spinics.net/lists/arm-kernel/msg80476.html I am fine with using bkpt as long as it helps us debug IT blocks and doesnt interfere with any of our currently functionality. http://reviews.llvm.org/D16853 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16868: [lldb] Fix invalid shift operator overload in Scalar
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. That's perfect. Thanks for adding that test. Do you have commit access, or shall I put this in? Repository: rL LLVM http://reviews.llvm.org/D16868 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
I think this is getting way too complicated. I haven't seen any test which needs such complicated combinations of skip conditions (and I hope I never see one). On 9 February 2016 at 01:24, Zachary Turner wrote: > 1. Skips if all conditions are true. @skipIf(all(A=a, B=b, C=c)) > 2. Skips if any condition is true. @skipIf(any(A=a, B=b, C=c)) This is equivalent to: @skipIf(A=a) @skipIf(B=b) @skipIf(C=c) which we already support. > 3. Skips if none of the conditions are true. @skipIf(none(A=a, B=b, C=c)) This can also be written as @skipIf(A=no_match(a), B=no_match(b), ...) I think it is a could idea to keep the skip conditions in some kind of a disjunctive normal form (as they are now), because it makes it clear what the decorator is going to do without having to do mental backflips to figure out the effect. I think the problem here is that you occasionally need to skip based on a strange condition, which cannot be expressed as a combination of existing flags, no matter how many combinators you add (linux distribution name, and android api level are the two that I can think of now), but these can be solved with passing a "function=" argument to @expectedFailureAll. If we see the same kind of a condition function passed to the decorator very often, then we probably need to figure out how to add that as one of the "standard" keyword arguments. pl ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
labath added a subscriber: labath. labath added a comment. I think this is getting way too complicated. I haven't seen any test which needs such complicated combinations of skip conditions (and I hope I never see one). Repository: rL LLVM http://reviews.llvm.org/D16936 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r260072 - [LLDB][MIPS] Fix TestExpressionInSyscall.py for MIPS
Hi Hans,
Could you please add this (r260072) to the release branch?
Thanks,
Bhushan
-Original Message-
From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On Behalf Of
Bhushan D. Attarde via lldb-commits
Sent: 08 February 2016 10:06
To: lldb-commits@lists.llvm.org
Subject: [Lldb-commits] [lldb] r260072 - [LLDB][MIPS] Fix
TestExpressionInSyscall.py for MIPS
Author: bhushan.attarde
Date: Sun Feb 7 22:35:51 2016
New Revision: 260072
URL: http://llvm.org/viewvc/llvm-project?rev=260072&view=rev
Log:
[LLDB][MIPS] Fix TestExpressionInSyscall.py for MIPS
SUMMARY:
This patch fixes TestExpressionInSyscall.py and solves bug 23659 for MIPS.
Corrected indentation at couple of places.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16916
Modified:
lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp
lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp
Modified: lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp?rev=260072&r1=260071&r2=260072&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp Sun Feb 7
22:35:51 2016
@@ -242,16 +242,27 @@ ABISysV_mips::PrepareTrivialCall (Thread
const RegisterInfo *sp_reg_info = reg_ctx->GetRegisterInfo
(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
const RegisterInfo *ra_reg_info = reg_ctx->GetRegisterInfo
(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_RA);
const RegisterInfo *r25_info = reg_ctx->GetRegisterInfoByName("r25", 0);
+const RegisterInfo *r0_info = reg_ctx->GetRegisterInfoByName("zero", 0);
if (log)
-log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
+log->Printf("Writing R0: 0x%" PRIx64, (uint64_t)0);
+
+/* Write r0 with 0, in case we are stopped in syscall,
+ * such setting prevents automatic decrement of the PC.
+ * This clears the bug 23659 for MIPS.
+*/
+if (!reg_ctx->WriteRegisterFromUnsigned (r0_info, (uint64_t)0))
+return false;
+
+if (log)
+log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
// Set "sp" to the requested value
if (!reg_ctx->WriteRegisterFromUnsigned (sp_reg_info, sp))
return false;
if (log)
-log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
+log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
// Set "ra" to the return address
if (!reg_ctx->WriteRegisterFromUnsigned (ra_reg_info, return_addr))
Modified: lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp?rev=260072&r1=260071&r2=260072&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp Sun Feb 7
22:35:51 2016
@@ -207,16 +207,27 @@ ABISysV_mips64::PrepareTrivialCall (Thre
const RegisterInfo *sp_reg_info = reg_ctx->GetRegisterInfo
(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
const RegisterInfo *ra_reg_info = reg_ctx->GetRegisterInfo
(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_RA);
const RegisterInfo *r25_info = reg_ctx->GetRegisterInfoByName("r25", 0);
+const RegisterInfo *r0_info = reg_ctx->GetRegisterInfoByName("zero", 0);
if (log)
-log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
+log->Printf("Writing R0: 0x%" PRIx64, (uint64_t)0);
+
+/* Write r0 with 0, in case we are stopped in syscall,
+ * such setting prevents automatic decrement of the PC.
+ * This clears the bug 23659 for MIPS.
+*/
+if (!reg_ctx->WriteRegisterFromUnsigned (r0_info, (uint64_t)0))
+return false;
+
+if (log)
+log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
// Set "sp" to the requested value
if (!reg_ctx->WriteRegisterFromUnsigned (sp_reg_info, sp))
return false;
if (log)
-log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
+log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
// Set "ra" to the return address
if (!reg_ctx->WriteRegisterFromUnsigned (ra_reg_info, return_addr))
___
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] r260216 - Fix a typo in an xfail decorator in TestExprsChar
Author: tberghammer
Date: Tue Feb 9 04:10:42 2016
New Revision: 260216
URL: http://llvm.org/viewvc/llvm-project?rev=260216&view=rev
Log:
Fix a typo in an xfail decorator in TestExprsChar
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py?rev=260216&r1=260215&r2=260216&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
Tue Feb 9 04:10:42 2016
@@ -57,7 +57,7 @@ class ExprCharTestCase(TestBase):
def test_default_char(self):
self.do_test()
-@expectedFailureAll(archs=["arm, aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
def test_signed_char(self):
self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D17022: [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
bhushan created this revision.
bhushan added reviewers: clayborg, spyffe.
bhushan added subscribers: lldb-commits, nitesh.jain, jaydeep, sagar,
mohit.bhakkad.
bhushan set the repository for this revision to rL LLVM.
Currently, LLDB (ClangExpressionParser) does not pass
`clang::TargetOptions::CPU` to clang which is supposed to contain the name of
the target CPU to generate code for.
So, compiler generates the code for its default CPU (mips32r2 and mips64r2 for
MIPS32 and MIPS64 respectively).
This causes problems in evaluating expressions in some cases.
For example, if we are debugging MIPS revision 6 (R6) application, as we do not
pass CPU information to the compiler so compiler chooses default target and
generates code for mips32r2/mips64r2.
The code generated for expression then fails to run on R6 because instruction
set differs for R2 and R6 (few instructions in R2 are not available in R6).
The causes expression to fail.
This patch sets `clang::TargetOptions::CPU` with appropriate string so that
compiler can generate correct code for that target.
Repository:
rL LLVM
http://reviews.llvm.org/D17022
Files:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -175,6 +175,10 @@
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
+ArchSpec arch;
+if (target_sp)
+arch = target_sp->GetArchitecture();
+
// TODO: figure out what to really do when we don't have a valid target.
// Sometimes this will be ok to just use the host target triple (when we
// evaluate say "2+3", but other expressions like breakpoint conditions
@@ -197,6 +201,50 @@
m_compiler->getTargetOpts().Features.push_back("+sse2");
}
+if (arch.GetMachine() == llvm::Triple::mips ||
+arch.GetMachine() == llvm::Triple::mipsel ||
+arch.GetMachine() == llvm::Triple::mips64 ||
+arch.GetMachine() == llvm::Triple::mips64el)
+{
+std::string cpu;
+switch (arch.GetCore())
+{
+case ArchSpec::eCore_mips32:
+case ArchSpec::eCore_mips32el:
+cpu = "mips32"; break;
+case ArchSpec::eCore_mips32r2:
+case ArchSpec::eCore_mips32r2el:
+cpu = "mips32r2"; break;
+case ArchSpec::eCore_mips32r3:
+case ArchSpec::eCore_mips32r3el:
+cpu = "mips32r3"; break;
+case ArchSpec::eCore_mips32r5:
+case ArchSpec::eCore_mips32r5el:
+cpu = "mips32r5"; break;
+case ArchSpec::eCore_mips32r6:
+case ArchSpec::eCore_mips32r6el:
+cpu = "mips32r6"; break;
+case ArchSpec::eCore_mips64:
+case ArchSpec::eCore_mips64el:
+cpu = "mips64"; break;
+case ArchSpec::eCore_mips64r2:
+case ArchSpec::eCore_mips64r2el:
+cpu = "mips64r2"; break;
+case ArchSpec::eCore_mips64r3:
+case ArchSpec::eCore_mips64r3el:
+cpu = "mips64r3"; break;
+case ArchSpec::eCore_mips64r5:
+case ArchSpec::eCore_mips64r5el:
+cpu = "mips64r5"; break;
+case ArchSpec::eCore_mips64r6:
+case ArchSpec::eCore_mips64r6el:
+cpu = "mips64r6"; break;
+default:
+cpu = "generic"; break;
+}
+m_compiler->getTargetOpts().CPU = cpu;
+}
+
// Any arm32 iOS environment, but not on arm64
if (m_compiler->getTargetOpts().Triple.find("arm64") == std::string::npos
&&
m_compiler->getTargetOpts().Triple.find("arm") != std::string::npos &&
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -175,6 +175,10 @@
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
+ArchSpec arch;
+if (target_sp)
+arch = target_sp->GetArchitecture();
+
// TODO: figure out what to really do when we don't have a valid target.
// Sometimes this will be ok to just use the host target triple (when we
// evaluate say "2+3", but other expressions like breakpoint conditions
@@ -197,6 +201,50 @@
m_compiler->getTargetOpts().Features.push_back("+sse2");
}
+if (arch.GetMachine() == llvm::Triple::mips ||
+arch.GetMachine() == llvm::Triple::mipsel ||
+arch.GetMachine() == llvm::Triple::mips64 ||
+arch.GetMachine() == llvm::Triple::mips64el)
+{
+std::string cpu;
+switch (arch.GetCore())
+{
+case ArchSpec::eCore_mips32:
+case ArchSpec::eCore_mips32el:
+cpu = "mips32"; b
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
tberghammer added a comment.
My main concern is that we have a lot of named argument for
skipIf/expectFailure and I expect it to increase even further as we support
more and more configuration. In my opinion we can have some functional style
solution as readable as the current solution with greater flexibility.
What do you think about having the skipIf decorator taking a list of functions
as argument with *argc and it's meaning is that the test is skipped if all
function returns true (skipIfAll)? To make it readable we can then write simple
helper functions such as: archMatches, compilerMatches, hostMatches, etc
In this case we can have decorators like this: @skipIf(archMatches("arm"),
compilerMatches("clang", "3.7"))
If we need some more complicated condition then we can either introduce logical
operators what can be used to negate functions, or/xor functions or do even
more complicated things based on the existing basic functions or we can
introduce new free standing functions what can be passed in to the decorator
(they can be specified either locally or globally)
A few complicated function I think we will need: androidDeviceMatches,
linuxDistributionMatches, deviceSupportsHardwareBreakpoints, etc...
I think this solution keeps the common decorators very readable while making
the system easily extensible for extreme situations.
Repository:
rL LLVM
http://reviews.llvm.org/D16936
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16853: Use BKPT instead of UDF for arm/thumb breakpoints
tberghammer added a comment. In http://reviews.llvm.org/D16853#347120, @omjavaid wrote: > GDB doesnt use bkpt instruction for user debugging for the reason that it > interferes with jtag debug probes. I am not sure if LLDB will be ever used > with a jtag probe in near future but still a jtag prob might be connected to > the same hardware which is using LLDB to debug a user space application. The change is restricted to Linux and I am pretty sure that if somebody want to do jtag debugging with LLDB then he/she have to implement a new platform module. If a separate jtag probe is connected to the hardware then it might cause an issue but I don't think we have any user who is doing it (why would you use 2 debugging at the same time?) > heres a discussion which happened some years back on similar issues: > > https://sourceware.org/ml/gdb-patches/2010-01/msg00624.html > > http://www.spinics.net/lists/arm-kernel/msg80476.html If we hit the issues they are mentioning with using the BKPT instruction then we have to implement some workarounds for it but as they describe they are not perfect so I would rather avoid them. > I am fine with using bkpt as long as it helps us debug IT blocks and doesnt > interfere with any of our currently functionality. I run the test suit and nothing showed up so I think we are mostly safe in this side. http://reviews.llvm.org/D16853 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16814: Fix handling of the arm IT instruction in the unwinder
tberghammer added a comment. Jason: Can you take at the change in the unwinding logic? Comment at: source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp:13653 @@ -13656,2 +13652,3 @@ const uint32_t cond = CurrentCond (m_opcode.GetOpcode32()); -return cond != 0xe && cond != 0xf && cond != UINT32_MAX; +if (cond == 0xe || cond == 0xf || cond == UINT32_MAX) +return EmulateInstruction::UnconditionalCondition; clayborg wrote: > Do you want to use UnconditionalCondition (or k_unconditional_condition) > instead of UINT32_MAX here? No, here we are inside EmulateInstructionARM. CurrentCond returns UINT32_MAX as a failure value what we want to treat as unconditional (as we can't do anything better). Changing CurrentCond to return UnconditionalCondition in case of a failure won't make any sense either. http://reviews.llvm.org/D16814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16680: Re-submit rL258759: Write the session log file in UTF-8.
tberghammer abandoned this revision. tberghammer added a comment. The change was submitted with a different CL http://reviews.llvm.org/D16680 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16868: [lldb] Fix invalid shift operator overload in Scalar
mamai added a comment. I don't have commit access. It would be great if you can push it for me. Thanks ! Repository: rL LLVM http://reviews.llvm.org/D16868 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16996: Improve the handling of missing elf symtab and missing symbol sizes
tberghammer updated this revision to Diff 47314.
http://reviews.llvm.org/D16996
Files:
include/lldb/Core/RangeMap.h
include/lldb/Symbol/DWARFCallFrameInfo.h
include/lldb/Symbol/ObjectFile.h
include/lldb/Symbol/Symtab.h
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.h
source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
source/Symbol/DWARFCallFrameInfo.cpp
source/Symbol/ObjectFile.cpp
source/Symbol/Symtab.cpp
Index: source/Symbol/Symtab.cpp
===
--- source/Symbol/Symtab.cpp
+++ source/Symbol/Symtab.cpp
@@ -894,35 +894,6 @@
addr_t match_offset;
} SymbolSearchInfo;
-static int
-SymbolWithClosestFileAddress (SymbolSearchInfo *info, const uint32_t *index_ptr)
-{
-const Symbol *symbol = info->symtab->SymbolAtIndex (index_ptr[0]);
-if (symbol == nullptr)
-return -1;
-
-const addr_t info_file_addr = info->file_addr;
-if (symbol->ValueIsAddress())
-{
-const addr_t curr_file_addr = symbol->GetAddressRef().GetFileAddress();
-if (info_file_addr < curr_file_addr)
-return -1;
-
-// Since we are finding the closest symbol that is greater than or equal
-// to 'info->file_addr' we set the symbol here. This will get set
-// multiple times, but after the search is done it will contain the best
-// symbol match
-info->match_symbol = const_cast(symbol);
-info->match_index_ptr = index_ptr;
-info->match_offset = info_file_addr - curr_file_addr;
-
-if (info_file_addr > curr_file_addr)
-return +1;
-return 0;
-}
-return -1;
-}
-
void
Symtab::InitAddressIndexes()
{
@@ -944,43 +915,33 @@
m_file_addr_to_index.Append(entry);
}
}
+
+lldb::addr_t total_size = 0;
+
const size_t num_entries = m_file_addr_to_index.GetSize();
if (num_entries > 0)
{
m_file_addr_to_index.Sort();
-m_file_addr_to_index.CalculateSizesOfZeroByteSizeRanges();
-
+
// Now our last symbols might not have had sizes because there
// was no subsequent symbol to calculate the size from. If this is
// the case, then calculate the size by capping it at the end of the
// section in which the symbol resides
for (int i = num_entries - 1; i >= 0; --i)
{
-const FileRangeToIndexMap::Entry &entry = m_file_addr_to_index.GetEntryRef(i);
-// As we iterate backwards, as soon as we find a symbol with a valid
-// byte size, we are done
+const FileRangeToIndexMap::Entry& entry = m_file_addr_to_index.GetEntryRef(i);
+
+// As we iterate backwards, as soon as we find a symbol with a valid byte size, we
+// are done.
if (entry.GetByteSize() > 0)
break;
-// Cap the size to the end of the section in which the symbol resides
-SectionSP section_sp (m_objfile->GetSectionList()->FindSectionContainingFileAddress (entry.GetRangeBase()));
-if (section_sp)
-{
-const lldb::addr_t end_section_file_addr = section_sp->GetFileAddress() + section_sp->GetByteSize();
-const lldb::addr_t symbol_file_addr = entry.GetRangeBase();
-if (end_section_file_addr > symbol_file_addr)
-{
-Symbol &symbol = m_symbols[entry.data];
-if (!symbol.GetByteSizeIsValid())
-{
-symbol.SetByteSize(end_section_file_addr - symbol_file_addr);
-symbol.SetSizeIsSynthesized(true);
-}
-}
-}
+const Address& address = m_symbols[entry.data].GetAddressRef();
+if (SectionSP section_sp = address.GetSection())
+total_size = entry.base + section_sp->GetByteSize() - address.GetOffset();
}
-// Sort again in case the range size changes the ordering
-m_file_addr_to_index.Sort();
+
+m_file_addr_to_index.CalculateSizesOfZeroByteSizeRanges(total_size);
}
}
}
@@ -1020,37 +981,18 @@
}
Symbol *
-Symtab::FindSymbolContainingFileAddress (addr_t file_addr, const uint32_t* indexes, uint32_t num_indexes)
+Symtab::FindSymbolAtFileAddress (addr_t file_addr)
{
Mutex::Locker locker (m_mutex);
+if (!m_file_addr_to_index_computed)
+InitAddressIndexes();
-
-SymbolSearchInfo info = { this, file_addr, nullptr, nullptr, 0 };
-
-::bsearch (&info,
- indexes,
- num_indexes,
- sizeof(uint32_t),
- (ComparisonFunction)SymbolWithClosestFileAddress
Re: [Lldb-commits] [PATCH] D16996: Improve the handling of missing elf symtab and missing symbol sizes
tberghammer added inline comments. Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2939 @@ +2938,3 @@ +symbol_id, // Symbol table index. +symbol_name, // Symbol name. +false, // Is the symbol name mangled? I moved the symbol name generation logic into ObjectFile and also changed ObjectFileMachO to use that one http://reviews.llvm.org/D16996 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D17027: [expression evaluator] Allow runtimes to execute custom LLVM ModulePasses over the generated IR at various stages after expression compilation.
ldrumm created this revision.
ldrumm added reviewers: jingham, spyffe.
ldrumm added a subscriber: lldb-commits.
During expression evaluation, the `ClangExpressionParser` preforms a number of
hard-coded fixups on the expression's IR before the module is assembled and
dispatched to be run in a `ThreadPlan`.
This patch allows the runtimes to register LLVM passes to be run over the
generated IR, that they may perform language or architechture-specfic fixups or
analyses over the generated expression.
This makes expression evaluation for plugins more flexible and allows
language-specific fixes to reside in their own module, rather than littering
the expression evaluator itself with language-specific fixes.
http://reviews.llvm.org/D17027
Files:
include/lldb/Expression/LLVMUserExpression.h
include/lldb/Target/LanguageRuntime.h
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -613,6 +613,30 @@
log->Printf("Found function %s for %s", function_name.AsCString(), m_expr.FunctionName());
}
+LLVMUserExpression::IRPasses custom_passes;
+{
+auto lang = m_expr.Language();
+if (log)
+log->Printf("%s - Currrent expression language is %s\n", __FUNCTION__,
+Language::GetNameForLanguageType(lang));
+
+if (lang != lldb::eLanguageTypeUnknown)
+{
+auto runtime = exe_ctx.GetProcessSP()->GetLanguageRuntime(lang);
+if (runtime)
+runtime->GetIRPasses(custom_passes);
+}
+}
+
+if (custom_passes.EarlyPasses)
+{
+if (log)
+log->Printf("%s - Running Early IR Passes from LanguageRuntime on expression module '%s'", __FUNCTION__,
+m_expr.FunctionName());
+
+custom_passes.EarlyPasses->run(*llvm_module_ap);
+}
+
execution_unit_sp.reset(new IRExecutionUnit (m_llvm_context, // handed off here
llvm_module_ap, // handed off here
function_name,
@@ -690,12 +714,22 @@
IRDynamicChecks ir_dynamic_checks(*process->GetDynamicCheckers(), function_name.AsCString());
-if (!ir_dynamic_checks.runOnModule(*execution_unit_sp->GetModule()))
+llvm::Module *module = execution_unit_sp->GetModule();
+if (!module || !ir_dynamic_checks.runOnModule(*module))
{
err.SetErrorToGenericError();
err.SetErrorString("Couldn't add dynamic checks to the expression");
return err;
}
+
+if (custom_passes.LatePasses)
+{
+if (log)
+log->Printf("%s - Running Late IR Passes from LanguageRuntime on expression module '%s'",
+__FUNCTION__, m_expr.FunctionName());
+
+custom_passes.LatePasses->run(*module);
+}
}
execution_unit_sp->GetRunnableInfo(err, func_addr, func_end);
Index: include/lldb/Target/LanguageRuntime.h
===
--- include/lldb/Target/LanguageRuntime.h
+++ include/lldb/Target/LanguageRuntime.h
@@ -22,6 +22,8 @@
#include "lldb/Core/ValueObject.h"
#include "lldb/Core/Value.h"
#include "lldb/Target/ExecutionContextScope.h"
+#include "lldb/Expression/LLVMUserExpression.h"
+
#include "clang/Basic/TargetOptions.h"
namespace lldb_private {
@@ -157,6 +159,13 @@
return false;
}
+// Called by ClangExpressionParser::PrepareForExecution to query for any custom LLVM IR passes
+// that need to be run before an expression is assembled and run.
+virtual bool
+GetIRPasses(LLVMUserExpression::IRPasses &custom_passes)
+{
+return false;
+}
protected:
//--
// Classes that inherit from LanguageRuntime can see and modify these
Index: include/lldb/Expression/LLVMUserExpression.h
===
--- include/lldb/Expression/LLVMUserExpression.h
+++ include/lldb/Expression/LLVMUserExpression.h
@@ -16,6 +16,9 @@
#include
#include
+// Other libraries and framework includes
+#include "llvm/IR/LegacyPassManager.h"
+
// Project includes
#include "lldb/Expression/UserExpression.h"
@@ -34,7 +37,18 @@
//--
class LLVMUserExpression : public UserExpression
{
- public:
+public:
+// The IRPasses struct is filled in by a runtime after an expre
[Lldb-commits] [PATCH] D17030: Add new option to lldb-server to display its version
tberghammer created this revision.
tberghammer added a reviewer: labath.
tberghammer added a subscriber: lldb-commits.
Add new option to lldb-server to display its version
http://reviews.llvm.org/D17030
Files:
tools/lldb-server/lldb-server.cpp
Index: tools/lldb-server/lldb-server.cpp
===
--- tools/lldb-server/lldb-server.cpp
+++ tools/lldb-server/lldb-server.cpp
@@ -9,6 +9,7 @@
#include "lldb/Initialization/SystemLifetimeManager.h"
#include "lldb/Initialization/SystemInitializerCommon.h"
+#include "lldb/lldb-private.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/Support/ManagedStatic.h"
@@ -22,9 +23,10 @@
display_usage (const char *progname)
{
fprintf(stderr, "Usage:\n"
+" %s v[ersion]\n"
" %s g[dbserver] [options]\n"
" %s p[latform] [options]\n"
-"Invoke subcommand for additional help\n", progname, progname);
+"Invoke subcommand for additional help\n", progname, progname,
progname);
exit(0);
}
@@ -57,20 +59,24 @@
display_usage(progname);
exit(option_error);
}
-else if (argv[1][0] == 'g')
-{
-initialize();
-main_gdbserver(argc, argv);
-terminate();
-}
-else if (argv[1][0] == 'p')
+
+switch (argv[1][0])
{
-initialize();
-main_platform(argc, argv);
-terminate();
-}
-else {
-display_usage(progname);
-exit(option_error);
+case 'g':
+initialize();
+main_gdbserver(argc, argv);
+terminate();
+break;
+case 'p':
+initialize();
+main_platform(argc, argv);
+terminate();
+break;
+case 'v':
+fprintf(stderr, "%s\n", lldb_private::GetVersion());
+break;
+default:
+display_usage(progname);
+exit(option_error);
}
}
Index: tools/lldb-server/lldb-server.cpp
===
--- tools/lldb-server/lldb-server.cpp
+++ tools/lldb-server/lldb-server.cpp
@@ -9,6 +9,7 @@
#include "lldb/Initialization/SystemLifetimeManager.h"
#include "lldb/Initialization/SystemInitializerCommon.h"
+#include "lldb/lldb-private.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/Support/ManagedStatic.h"
@@ -22,9 +23,10 @@
display_usage (const char *progname)
{
fprintf(stderr, "Usage:\n"
+" %s v[ersion]\n"
" %s g[dbserver] [options]\n"
" %s p[latform] [options]\n"
-"Invoke subcommand for additional help\n", progname, progname);
+"Invoke subcommand for additional help\n", progname, progname, progname);
exit(0);
}
@@ -57,20 +59,24 @@
display_usage(progname);
exit(option_error);
}
-else if (argv[1][0] == 'g')
-{
-initialize();
-main_gdbserver(argc, argv);
-terminate();
-}
-else if (argv[1][0] == 'p')
+
+switch (argv[1][0])
{
-initialize();
-main_platform(argc, argv);
-terminate();
-}
-else {
-display_usage(progname);
-exit(option_error);
+case 'g':
+initialize();
+main_gdbserver(argc, argv);
+terminate();
+break;
+case 'p':
+initialize();
+main_platform(argc, argv);
+terminate();
+break;
+case 'v':
+fprintf(stderr, "%s\n", lldb_private::GetVersion());
+break;
+default:
+display_usage(progname);
+exit(option_error);
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r260072 - [LLDB][MIPS] Fix TestExpressionInSyscall.py for MIPS
Merged in r260236.
Thanks,
Hans
On Tue, Feb 9, 2016 at 1:40 AM, Bhushan Attarde
wrote:
> Hi Hans,
>
> Could you please add this (r260072) to the release branch?
>
> Thanks,
> Bhushan
>
>
> -Original Message-
> From: lldb-commits [mailto:lldb-commits-boun...@lists.llvm.org] On Behalf Of
> Bhushan D. Attarde via lldb-commits
> Sent: 08 February 2016 10:06
> To: lldb-commits@lists.llvm.org
> Subject: [Lldb-commits] [lldb] r260072 - [LLDB][MIPS] Fix
> TestExpressionInSyscall.py for MIPS
>
> Author: bhushan.attarde
> Date: Sun Feb 7 22:35:51 2016
> New Revision: 260072
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260072&view=rev
> Log:
> [LLDB][MIPS] Fix TestExpressionInSyscall.py for MIPS
>
> SUMMARY:
> This patch fixes TestExpressionInSyscall.py and solves bug 23659 for MIPS.
> Corrected indentation at couple of places.
>
> Reviewers: clayborg
> Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
> Differential Revision: http://reviews.llvm.org/D16916
>
> Modified:
> lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp
> lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp
>
> Modified: lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp?rev=260072&r1=260071&r2=260072&view=diff
> ==
> --- lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp (original)
> +++ lldb/trunk/source/Plugins/ABI/SysV-mips/ABISysV_mips.cpp Sun Feb 7
> 22:35:51 2016
> @@ -242,16 +242,27 @@ ABISysV_mips::PrepareTrivialCall (Thread
> const RegisterInfo *sp_reg_info = reg_ctx->GetRegisterInfo
> (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
> const RegisterInfo *ra_reg_info = reg_ctx->GetRegisterInfo
> (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_RA);
> const RegisterInfo *r25_info = reg_ctx->GetRegisterInfoByName("r25", 0);
> +const RegisterInfo *r0_info = reg_ctx->GetRegisterInfoByName("zero", 0);
>
> if (log)
> -log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
> +log->Printf("Writing R0: 0x%" PRIx64, (uint64_t)0);
> +
> +/* Write r0 with 0, in case we are stopped in syscall,
> + * such setting prevents automatic decrement of the PC.
> + * This clears the bug 23659 for MIPS.
> +*/
> +if (!reg_ctx->WriteRegisterFromUnsigned (r0_info, (uint64_t)0))
> +return false;
> +
> +if (log)
> +log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
>
> // Set "sp" to the requested value
> if (!reg_ctx->WriteRegisterFromUnsigned (sp_reg_info, sp))
> return false;
>
> if (log)
> -log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
> +log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
>
> // Set "ra" to the return address
> if (!reg_ctx->WriteRegisterFromUnsigned (ra_reg_info, return_addr))
>
> Modified: lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp?rev=260072&r1=260071&r2=260072&view=diff
> ==
> --- lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp (original)
> +++ lldb/trunk/source/Plugins/ABI/SysV-mips64/ABISysV_mips64.cpp Sun Feb 7
> 22:35:51 2016
> @@ -207,16 +207,27 @@ ABISysV_mips64::PrepareTrivialCall (Thre
> const RegisterInfo *sp_reg_info = reg_ctx->GetRegisterInfo
> (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
> const RegisterInfo *ra_reg_info = reg_ctx->GetRegisterInfo
> (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_RA);
> const RegisterInfo *r25_info = reg_ctx->GetRegisterInfoByName("r25", 0);
> +const RegisterInfo *r0_info = reg_ctx->GetRegisterInfoByName("zero", 0);
>
> if (log)
> -log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
> +log->Printf("Writing R0: 0x%" PRIx64, (uint64_t)0);
> +
> +/* Write r0 with 0, in case we are stopped in syscall,
> + * such setting prevents automatic decrement of the PC.
> + * This clears the bug 23659 for MIPS.
> +*/
> +if (!reg_ctx->WriteRegisterFromUnsigned (r0_info, (uint64_t)0))
> +return false;
> +
> +if (log)
> +log->Printf("Writing SP: 0x%" PRIx64, (uint64_t)sp);
>
> // Set "sp" to the requested value
> if (!reg_ctx->WriteRegisterFromUnsigned (sp_reg_info, sp))
> return false;
>
> if (log)
> -log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
> +log->Printf("Writing RA: 0x%" PRIx64, (uint64_t)return_addr);
>
> // Set "ra" to the return address
> if (!reg_ctx->WriteRegisterFromUnsigned (ra_reg_info, return_addr))
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman
[Lldb-commits] [lldb] r260239 - Fix invalid shift operator overload in Scalar
Author: labath
Date: Tue Feb 9 11:28:01 2016
New Revision: 260239
URL: http://llvm.org/viewvc/llvm-project?rev=260239&view=rev
Log:
Fix invalid shift operator overload in Scalar
Summary: This also fixes an infinite recursion between lldb_private::operator>>
() and Scalar::operator>>= ().
Reviewers: sagar, tberghammer, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16868
Patch by Marianne Mailhot-Sarrasin
Added:
lldb/trunk/unittests/Core/
lldb/trunk/unittests/Core/CMakeLists.txt
lldb/trunk/unittests/Core/ScalarTest.cpp
Modified:
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/unittests/CMakeLists.txt
Modified: lldb/trunk/source/Core/Scalar.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=260239&r1=260238&r2=260239&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Tue Feb 9 11:28:01 2016
@@ -1875,7 +1875,7 @@ Scalar::operator>>= (const Scalar& rhs)
case e_sint128:
case e_uint128:
{
- m_integer >> *rhs.m_integer.getRawData();
+ m_integer = m_integer.ashr(*(const uint_t
*)rhs.m_integer.getRawData());
break;
}
}
Modified: lldb/trunk/unittests/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/CMakeLists.txt?rev=260239&r1=260238&r2=260239&view=diff
==
--- lldb/trunk/unittests/CMakeLists.txt (original)
+++ lldb/trunk/unittests/CMakeLists.txt Tue Feb 9 11:28:01 2016
@@ -23,6 +23,7 @@ function(add_lldb_unittest test_name)
llvm_config(${test_name} ${LLVM_LINK_COMPONENTS})
endfunction()
+add_subdirectory(Core)
add_subdirectory(Editline)
add_subdirectory(Expression)
add_subdirectory(Host)
Added: lldb/trunk/unittests/Core/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Core/CMakeLists.txt?rev=260239&view=auto
==
--- lldb/trunk/unittests/Core/CMakeLists.txt (added)
+++ lldb/trunk/unittests/Core/CMakeLists.txt Tue Feb 9 11:28:01 2016
@@ -0,0 +1,3 @@
+add_lldb_unittest(CoreTests
+ ScalarTest.cpp
+ )
Added: lldb/trunk/unittests/Core/ScalarTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Core/ScalarTest.cpp?rev=260239&view=auto
==
--- lldb/trunk/unittests/Core/ScalarTest.cpp (added)
+++ lldb/trunk/unittests/Core/ScalarTest.cpp Tue Feb 9 11:28:01 2016
@@ -0,0 +1,32 @@
+//===-- ScalarTest.cpp --*- C++
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#if defined(_MSC_VER) && (_HAS_EXCEPTIONS == 0)
+// Workaround for MSVC standard library bug, which fails to include
when
+// exceptions are disabled.
+#include
+#endif
+
+#include "gtest/gtest.h"
+
+#include "lldb/Core/Scalar.h"
+
+using namespace lldb_private;
+
+TEST(ScalarTest, RightShiftOperator)
+{
+int a = 0x1000;
+int b = 0x;
+int c = 4;
+Scalar a_scalar(a);
+Scalar b_scalar(b);
+Scalar c_scalar(c);
+ASSERT_EQ(a >> c, a_scalar >> c_scalar);
+ASSERT_EQ(b >> c, b_scalar >> c_scalar);
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16868: [lldb] Fix invalid shift operator overload in Scalar
labath closed this revision. labath added a comment. Committed as r260239. Repository: rL LLVM http://reviews.llvm.org/D16868 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
zturner added a comment. In http://reviews.llvm.org/D16936#347141, @labath wrote: > I think this is getting way too complicated. I haven't seen any test > which needs such complicated combinations of skip conditions (and I > hope I never see one). I agree that you don't need arbitrary complexity, but I think there are some things we would greatly benefit from. For example, have you ever seen this? @expectedFailureWindows @expectedFailureGcc @expectedFailureHostLinux That's 3 decorators, when you could write it as 1: @expectedFailure(or(oslist="windows", compiler="gcc", hostoslist="linux")) The rest of the functionality I mentioned you practically get for free if you support this. Repository: rL LLVM http://reviews.llvm.org/D16936 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
zturner added a comment.
In http://reviews.llvm.org/D16936#347186, @tberghammer wrote:
> My main concern is that we have a lot of named argument for
> skipIf/expectFailure and I expect it to increase even further as we support
> more and more configuration. In my opinion we can have some functional style
> solution as readable as the current solution with greater flexibility.
>
> What do you think about having the skipIf decorator taking a list of
> functions as argument with *argc and it's meaning is that the test is skipped
> if all function returns true (skipIfAll)? To make it readable we can then
> write simple helper functions such as: archMatches, compilerMatches,
> hostMatches, etc
>
> In this case we can have decorators like this: @skipIf(archMatches("arm"),
> compilerMatches("clang", "3.7"))
>
> If we need some more complicated condition then we can either introduce
> logical operators what can be used to negate functions, or/xor functions or
> do even more complicated things based on the existing basic functions or we
> can introduce new free standing functions what can be passed in to the
> decorator (they can be specified either locally or globally)
>
> A few complicated function I think we will need: androidDeviceMatches,
> linuxDistributionMatches, deviceSupportsHardwareBreakpoints, etc...
>
> I think this solution keeps the common decorators very readable while making
> the system easily extensible for extreme situations.
Something like that might be ok. I do agree that we can't support every use
case through keyword arguments, that would be a little crazy. So we have to
decide whether we want to use functional style for everything, or keep keyword
style for some very common use cases and functional style for everything else.
Maybe functional style for everything is better, I'll have to think about it
some though.
Repository:
rL LLVM
http://reviews.llvm.org/D16936
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
On 9 February 2016 at 17:51, Zachary Turner wrote: > I agree that you don't need arbitrary complexity, but I think there are some > things we would greatly benefit from. For example, have you ever seen this? > > @expectedFailureWindows > @expectedFailureGcc > @expectedFailureHostLinux > > That's 3 decorators, when you could write it as 1: > > @expectedFailure(or(oslist="windows", compiler="gcc", hostoslist="linux")) Maybe that's a matter of preference, but I would much rather see the former than the latter. What I would like to avoid is having two decorators like: @xfail(or(a=A, not(b=B)), c=C') @xfail(a=A', or(b=B', not(c=C'))) on a single test. At that point it becomes quite impossible to figure out when the test gets run. Also, arguably, if you are doing "or", then you are probably dealing with separate bugs, and each should deserve it's own bugnumber. pl ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17027: [expression evaluator] Allow runtimes to execute custom LLVM ModulePasses over the generated IR at various stages after expression compilation.
jingham added a comment. This seems fine as a generic instrumentation point. Obviously, the onus in on the passes, since they could totally ruin the expression evaluation if they don't do their job right... But I'm not sure there's any good way to make this not a sharp tool. But you should wait on Sean to weigh in as well... One question, what is the force of the "legacy" in "llvm::legacy::PassManager? Is there some more "modern" way to do this, is this going to go away at some point? http://reviews.llvm.org/D17027 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
True about the bugnumbers. Not always diferent bug numbers, but certainly
sometimes.
The reason I don't like writing them as separate decorators is because we
have tons of cases where the condition of multiple decorators pass, and the
best we can do is report one bugnumber / reason in the output because we
don't even evaluate the rest after that. If the entire conditional is
specified on one decorator, you can support that.
With functional style you could still support multiple bugnumbers on an or
conditional like this:
@xfail(or(compiler("gcc", [">=", 4.7], bugnumber=12345), hostos("windows",
bugnumber=23456)))
which is equivalent to:
@xfail(compiler="gcc", compiler_version=[">=", 4.7], bugnumber=12345)
@xfail(hostoslist="windows", bugnumber=23456)
I think also having many layers of decorator nesting provides an
implementation challenge. Ultimately we would like to re-use the skipif
functionality of unittest / unittest2 (especially since we want to port to
unittest). So it would be nice if we could write our decorator like this:
def skipIf(...):
def fn(...):
...
unittest2.skipIf(fn)
Right now we can't do this because the nature of the nested decorators
requires us to hack together our own implementation of skipif so that we
can manually call into the next decorator under the right conditions. If
we have just one decorator, it's much easier to write it in terms of
unittest.skipIf. Just construct the function that evaluates the condition,
and pass it in to unittest.
(For what it's worth, I'm not planning to do any of this extra stuff right
now, or even soon, so this is all theoretical at this point. Right now I
just want to remove low hanging fruit and reduce the number of decorators,
but not get it down all the way to 2).
On Tue, Feb 9, 2016 at 10:29 AM Pavel Labath wrote:
> On 9 February 2016 at 17:51, Zachary Turner wrote:
> > I agree that you don't need arbitrary complexity, but I think there are
> some things we would greatly benefit from. For example, have you ever seen
> this?
> >
> > @expectedFailureWindows
> > @expectedFailureGcc
> > @expectedFailureHostLinux
> >
> > That's 3 decorators, when you could write it as 1:
> >
> > @expectedFailure(or(oslist="windows", compiler="gcc",
> hostoslist="linux"))
>
> Maybe that's a matter of preference, but I would much rather see the
> former than the latter.
>
> What I would like to avoid is having two decorators like:
> @xfail(or(a=A, not(b=B)), c=C')
> @xfail(a=A', or(b=B', not(c=C')))
> on a single test. At that point it becomes quite impossible to figure
> out when the test gets run.
>
> Also, arguably, if you are doing "or", then you are probably dealing
> with separate bugs, and each should deserve it's own bugnumber.
>
> pl
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16936: Remove expectedFailureWindows decorator
zturner added a subscriber: zturner.
zturner added a comment.
True about the bugnumbers. Not always diferent bug numbers, but certainly
sometimes.
The reason I don't like writing them as separate decorators is because we
have tons of cases where the condition of multiple decorators pass, and the
best we can do is report one bugnumber / reason in the output because we
don't even evaluate the rest after that. If the entire conditional is
specified on one decorator, you can support that.
With functional style you could still support multiple bugnumbers on an or
conditional like this:
@xfail(or(compiler("gcc", [">=", 4.7], bugnumber=12345), hostos("windows",
bugnumber=23456)))
which is equivalent to:
@xfail(compiler="gcc", compiler_version=[">=", 4.7], bugnumber=12345)
@xfail(hostoslist="windows", bugnumber=23456)
I think also having many layers of decorator nesting provides an
implementation challenge. Ultimately we would like to re-use the skipif
functionality of unittest / unittest2 (especially since we want to port to
unittest). So it would be nice if we could write our decorator like this:
def skipIf(...):
def fn(...):
...
unittest2.skipIf(fn)
Right now we can't do this because the nature of the nested decorators
requires us to hack together our own implementation of skipif so that we
can manually call into the next decorator under the right conditions. If
we have just one decorator, it's much easier to write it in terms of
unittest.skipIf. Just construct the function that evaluates the condition,
and pass it in to unittest.
(For what it's worth, I'm not planning to do any of this extra stuff right
now, or even soon, so this is all theoretical at this point. Right now I
just want to remove low hanging fruit and reduce the number of decorators,
but not get it down all the way to 2).
Repository:
rL LLVM
http://reviews.llvm.org/D16936
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260247 - Mention the --all-files option in the -p help string.
Author: jingham
Date: Tue Feb 9 12:53:49 2016
New Revision: 260247
URL: http://llvm.org/viewvc/llvm-project?rev=260247&view=rev
Log:
Mention the --all-files option in the -p help string.
Modified:
lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp
Modified: lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp?rev=260247&r1=260246&r2=260247&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp Tue Feb 9 12:53:49
2016
@@ -820,7 +820,8 @@ CommandObjectBreakpointSet::CommandOptio
{ LLDB_OPT_SET_9, true, "source-pattern-regexp", 'p',
OptionParser::eRequiredArgument, NULL, NULL, 0, eArgTypeRegularExpression,
"Set the breakpoint by specifying a regular expression which is
matched against the source text in a source file or files "
"specified with the -f option. The -f option can be specified more
than once. "
-"If no source files are specified, uses the current \"default source
file\"" },
+"If no source files are specified, uses the current \"default source
file\". "
+"If you want to match against all source files, pass the
\"--all-files\" option." },
{ LLDB_OPT_SET_9, false, "all-files", 'A', OptionParser::eNoArgument,
NULL, NULL, 0, eArgTypeNone,
"All files are searched for source pattern matches." },
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17022: [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
We should use local variable and avoid calling accessors many times. See
inlined comments. I know the code was like this before, but we should fix these
things as we go.
Comment at: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:178
@@ -177,1 +177,3 @@
+ArchSpec arch;
+if (target_sp)
name this "target_arch"
Comment at:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:197-198
@@ -192,4 +196,4 @@
if (target_sp->GetArchitecture().GetMachine() == llvm::Triple::x86 ||
target_sp->GetArchitecture().GetMachine() == llvm::Triple::x86_64)
{
Many people are playing with the Target arhitecture's machine, please put this
in a local variable and use it to avoid calling the access many times.
```
const auto target_machine = target_arch.GetMachine();
```
Comment at:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:204-208
@@ -199,1 +203,7 @@
+if (arch.GetMachine() == llvm::Triple::mips ||
+arch.GetMachine() == llvm::Triple::mipsel ||
+arch.GetMachine() == llvm::Triple::mips64 ||
+arch.GetMachine() == llvm::Triple::mips64el)
+{
+std::string cpu;
Use "target_machine"
Repository:
rL LLVM
http://reviews.llvm.org/D17022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16853: Use BKPT instead of UDF for arm/thumb breakpoints
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Looks good. Most JTAG probes actually vend their own GDB server these days. If so, we will used the Z packets in order to set breakpoints, so we will be isolated from these issues. If we add a native JTAG Process plug-in, it will be coded to "do the right thing" and it won't re-use this code, so this code should be good to go. http://reviews.llvm.org/D16853 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16814: Fix handling of the arm IT instruction in the unwinder
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Looks good. http://reviews.llvm.org/D16814 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16996: Improve the handling of missing elf symtab and missing symbol sizes
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Looks good. http://reviews.llvm.org/D16996 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260282 - Don't enable -flimit-debug-info by default for the LLDB Xcode builds. This was put in back in 2011 when -flimit-debug-info did a lot less than it does now. With llvm-ds
Author: gclayton Date: Tue Feb 9 15:18:44 2016 New Revision: 260282 URL: http://llvm.org/viewvc/llvm-project?rev=260282&view=rev Log: Don't enable -flimit-debug-info by default for the LLDB Xcode builds. This was put in back in 2011 when -flimit-debug-info did a lot less than it does now. With llvm-dsymutil doing ODR type unique stuff we still have reasonably sized dSYM files. Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=260282&r1=260281&r2=260282&view=diff == --- lldb/trunk/lldb.xcodeproj/project.pbxproj (original) +++ lldb/trunk/lldb.xcodeproj/project.pbxproj Tue Feb 9 15:18:44 2016 @@ -7280,7 +7280,6 @@ MACOSX_DEPLOYMENT_TARGET = 10.9; ONLY_ACTIVE_ARCH = YES; OTHER_CFLAGS = ( - "-flimit-debug-info", "-Wparentheses", "$(LLDB_ZLIB_CFLAGS)", "$(LLDB_COMPRESSION_CFLAGS)", @@ -7366,7 +7365,6 @@ MACOSX_DEPLOYMENT_TARGET = 10.9; ONLY_ACTIVE_ARCH = YES; OTHER_CFLAGS = ( - "-flimit-debug-info", "-Wparentheses", "$(LLDB_ZLIB_CFLAGS)", "$(LLDB_COMPRESSION_CFLAGS)", @@ -7492,7 +7490,6 @@ LLDB_GTESTS_CFLAGS = "-I $(LLVM_SOURCE_DIR)/utils/unittest/googletest/include -I $(LLVM_SOURCE_DIR)/include -I $(LLVM_BUILD_DIR)/x86_64/include -I include -I source -I $(PYTHON_FRAMEWORK_PATH)/Headers"; LLDB_GTESTS_LDFLAGS = "$(LLVM_BUILD_DIR)/x86_64/lib/libgtest.a -L $(PYTHON_FRAMEWORK_PATH)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/lib -l python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)"; OTHER_CFLAGS = ( - "-flimit-debug-info", "-Wparentheses", "$(LLDB_ZLIB_CFLAGS)", "$(LLDB_COMPRESSION_CFLAGS)", @@ -7529,7 +7526,6 @@ LLDB_GTESTS_CFLAGS = "-I $(LLVM_SOURCE_DIR)/utils/unittest/googletest/include -I $(LLVM_SOURCE_DIR)/include -I $(LLVM_BUILD_DIR)/x86_64/include -I include -I source -I $(PYTHON_FRAMEWORK_PATH)/Headers"; LLDB_GTESTS_LDFLAGS = "$(LLVM_BUILD_DIR)/x86_64/lib/libgtest.a -L $(PYTHON_FRAMEWORK_PATH)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/lib -l python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)"; OTHER_CFLAGS = ( - "-flimit-debug-info", "-Wparentheses", "$(LLDB_ZLIB_CFLAGS)", "$(LLDB_COMPRESSION_CFLAGS)", @@ -7566,7 +7562,6 @@ LLDB_GTESTS_CFLAGS = "-I $(LLVM_SOURCE_DIR)/utils/unittest/googletest/include -I $(LLVM_SOURCE_DIR)/include -I $(LLVM_BUILD_DIR)/x86_64/include -I include -I source -I $(PYTHON_FRAMEWORK_PATH)/Headers"; LLDB_GTESTS_LDFLAGS = "$(LLVM_BUILD_DIR)/x86_64/lib/libgtest.a -L $(PYTHON_FRAMEWORK_PATH)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/lib -l python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)"; OTHER_CFLAGS = ( - "-flimit-debug-info", "-Wparentheses", "$(LLDB_ZLIB_CFLAGS)", "$(LLDB_COMPRESSION_CFLAGS)", @@ -7603,7 +7598,6 @@ LLDB_GTESTS_CFLAGS = "-I $(LLVM_SOURCE_DIR)/utils/unittest/googletest/include -I $(LLVM_SOURCE_DIR)/include -I $(LLVM_BUILD_DIR)/x86_64/include -I include -I source -I $(PYTHON_FRAMEWORK_PATH)/Headers"; LLDB_GTESTS_LDFLAGS = "$(LLVM_BUILD_DIR)/x86_64/lib/libgtest.a -L $(PYTHON_FRAMEWORK_PATH)/Versions/$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)/lib -l python$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)"; OTHER_CFLAGS = ( - "-flimit-debug-info", "-Wparentheses", "$(LLDB_ZLIB_CFLAGS)", "$(LLDB_COMPRESSION_CFLAGS)", @@ -8076,7 +8070,6 @@ L
[Lldb-commits] [lldb] r260284 - If we set the DYLD_INSERT_LIBRARIES environment variable when launching debugserver, for use with /usr/lib/libgmalloc.dylib, then make sure we don't pass this environme
Author: gclayton
Date: Tue Feb 9 15:20:17 2016
New Revision: 260284
URL: http://llvm.org/viewvc/llvm-project?rev=260284&view=rev
Log:
If we set the DYLD_INSERT_LIBRARIES environment variable when launching
debugserver, for use with /usr/lib/libgmalloc.dylib, then make sure we don't
pass this environment variable on to any child processes.
Modified:
lldb/trunk/tools/debugserver/source/debugserver.cpp
Modified: lldb/trunk/tools/debugserver/source/debugserver.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/debugserver.cpp?rev=260284&r1=260283&r2=260284&view=diff
==
--- lldb/trunk/tools/debugserver/source/debugserver.cpp (original)
+++ lldb/trunk/tools/debugserver/source/debugserver.cpp Tue Feb 9 15:20:17 2016
@@ -885,6 +885,10 @@ static struct option g_long_options[] =
int
main (int argc, char *argv[])
{
+// If debugserver is launched with DYLD_INSERT_LIBRARIES, unset it so we
+// don't spawn child processes with this enabled.
+unsetenv("DYLD_INSERT_LIBRARIES");
+
const char *argv_sub_zero = argv[0]; // save a copy of argv[0] for error
reporting post-launch
#if defined (__APPLE__)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260288 - Remove expected failure and skip decorators for host os.
Author: zturner
Date: Tue Feb 9 15:36:02 2016
New Revision: 260288
URL: http://llvm.org/viewvc/llvm-project?rev=260288&view=rev
Log:
Remove expected failure and skip decorators for host os.
All decorator invocations are updated to use the generic
expectedFailureAll and skipIf decorators.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/decorators.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/format/TestFormats.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hook/TestStopHookMechanism.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hook/multiple_threads/TestStopHookMultipleThreads.py
lldb/trunk/packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.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=260288&r1=260287&r2=260288&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Tue Feb 9 15:36:02
2016
@@ -319,9 +319,6 @@ def expectedFailureIcc(bugnumber=None):
def expectedFailureOS(oslist, bugnumber=None, compilers=None, debug_info=None,
archs=None):
return expectedFailureAll(oslist=oslist, bugnumber=bugnumber,
compiler=compilers, archs=archs, debug_info=debug_info)
-def expectedFailureHostOS(oslist, bugnumber=None, compilers=None):
-return expectedFailureAll(hostoslist=oslist, bugnumber=bugnumber)
-
def expectedFailureDarwin(bugnumber=None, compilers=None, debug_info=None):
# For legacy reasons, we support both "darwin" and "macosx" as OS X
triples.
return expectedFailureOS(lldbplatformutil.getDarwinOSTriples(), bugnumber,
compilers, debug_info=debug_info)
@@ -335,9 +332,6 @@ def expectedFailureLinux(bugnumber=None,
def expectedFailureNetBSD(bugnumber=None, compilers=None, debug_info=None):
return expectedFailureOS(['netbsd'], bugnumber, compilers,
debug_info=debug_info)
-def expectedFailureHostWindows(bugnumber=None, compilers=None):
-return expectedFailureHostOS(['windows'], bugnumber, compilers)
-
def expectedFailureAndroid(bugnumber=None, api_levels=None, archs=None):
""" Mark a test as xfail for Android.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py?rev=260288&r1=260287&r2=260288&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py
Tue Feb 9 15:36:02 2016
@@ -16,7 +16,7 @@ class CommandRegexTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
-@expectedFailureHostWindows("llvm.org/pr22274: need a pexpect replacement
for windows")
+@expectedFailureAll(hostoslist=["windows"], bugnumber="llvm.org/pr22274:
need a pexpect replacement for windows")
@no_debug_info_test
def test_command_regex(self):
"""Test a simple scenario of 'command regex' invocation and subsequent
use."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py?rev=260288&r1=260287&r2=260288&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py
Tue Feb 9 15:36:02 2016
@@ -25,21 +25,21 @@ class CommandLineCompletionTestCase(Test
except:
pass
-@expectedFailureHostWindows("llvm.org/pr24679")
+@expectedFailureAll(hostoslist=["windows"], bugnumber="llvm.org/pr24679")
@skipIfFreeBSD # timing out on the FreeBSD buildbot
@no_debug_info_test
def test_at(self):
"""Test that 'at' completes to 'attach '."""
self.complete_from_to('at', 'attach ')
-@expectedFailureHostWindows("llvm.org/pr24679")
+@expectedFailureAll(hostoslist=["windows"], bugnumber="llvm.org/pr24679")
@skipIfFreeBSD # timing out on the FreeBSD buildbot
@no_debug_info_test
def test_de(self):
[Lldb-commits] [lldb] r260292 - Fix incorrect usage of `str` in _match_decorator_property.
Author: zturner Date: Tue Feb 9 15:36:38 2016 New Revision: 260292 URL: http://llvm.org/viewvc/llvm-project?rev=260292&view=rev Log: Fix incorrect usage of `str` in _match_decorator_property. 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=260292&r1=260291&r2=260292&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Tue Feb 9 15:36:38 2016 @@ -62,7 +62,7 @@ def _match_decorator_property(expected, if isinstance(expected, no_match): return not _match_decorator_property(expected.item, actual) -elif isinstance(expected, (str, re._pattern_type)): +elif isinstance(expected, (re._pattern_type,)+six.string_types): return re.search(expected, actual) is not None elif hasattr(expected, "__iter__"): return any([x is not None and _match_decorator_property(x, actual) for x in expected]) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260290 - Remove decorators related to debug info types.
Author: zturner
Date: Tue Feb 9 15:36:23 2016
New Revision: 260290
URL: http://llvm.org/viewvc/llvm-project?rev=260290&view=rev
Log:
Remove decorators related to debug info types.
All existing usages were ported over to the common decorators.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/decorators.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/hidden-ivars/TestHiddenIvars.py
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-ivar-stripped/TestObjCIvarStripped.py
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.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=260290&r1=260289&r2=260290&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Tue Feb 9 15:36:23
2016
@@ -291,15 +291,6 @@ def not_remote_testsuite_ready(func):
return "Not ready for remote testsuite" if lldb.remote_platform else
None
return skipTestIfFn(is_remote)(func)
-def expectedFailureDwarf(bugnumber=None):
-return expectedFailureAll(bugnumber=bugnumber, debug_info="dwarf")
-
-def expectedFailureDwo(bugnumber=None):
-return expectedFailureAll(bugnumber=bugnumber, debug_info="dwo")
-
-def expectedFailureDsym(bugnumber=None):
-return expectedFailureAll(bugnumber=bugnumber, debug_info="dsym")
-
def expectedFailureOS(oslist, bugnumber=None, compilers=None, debug_info=None,
archs=None):
return expectedFailureAll(oslist=oslist, bugnumber=bugnumber,
compiler=compilers, archs=archs, debug_info=debug_info)
@@ -519,18 +510,6 @@ def skipUnlessPlatform(oslist):
"requires on of %s" % (", ".join(oslist)))
-def skipIfDebugInfo(bugnumber=None, debug_info=None):
-return skipIf(bugnumber=bugnumber, debug_info=debug_info)
-
-def skipIfDWO(bugnumber=None):
-return skipIfDebugInfo(bugnumber, ["dwo"])
-
-def skipIfDwarf(bugnumber=None):
-return skipIfDebugInfo(bugnumber, ["dwarf"])
-
-def skipIfDsym(bugnumber=None):
-return skipIfDebugInfo(bugnumber, ["dsym"])
-
def skipIfGcc(func):
"""Decorate the item to skip tests that should be skipped if building with
gcc ."""
return skipIf(compiler="gcc")(func)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py?rev=260290&r1=260289&r2=260290&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
Tue Feb 9 15:36:23 2016
@@ -11,7 +11,7 @@ class TestMacros(TestBase):
mydir = TestBase.compute_mydir(__file__)
@expectedFailureAll(compiler="clang", bugnumber="clang does not emit
.debug_macro[.dwo] sections.")
-@expectedFailureDwo("GCC produces multiple .debug_macro.dwo sections and
the spec is unclear as to what it means")
+@expectedFailureAll(debug_info="dwo", bugnumber="GCC produces multiple
.debug_macro.dwo sections and the spec is unclear as to what it means")
@expectedFailureAll(hostoslist=["windows"], compiler="gcc",
triple='.*-android')
def test_expr_with_macros(self):
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py?rev=260290&r1=260289&r2=260290&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
Tue Feb 9 15:36:23 2016
@@ -17,7 +17,7 @@ class DeadStripTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
-@expectedFailureDwo("llvm.org/pr25087")
+@expectedFailureAll(debug_info="dwo", bugnumber="llvm.org/pr25087")
@skipIfFreeBSD # The -dead_strip linker option isn't supported on FreeBSD
versions of ld.
def test(self):
"""Test breakpoint works correctly with dead-code stripping."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/hidden-ivars/TestHiddenIvars.py
URL:
http://llvm.org/viewvc/llvm
[Lldb-commits] [lldb] r260289 - Delete all the xfail / skip decorators for specific compilers.
Author: zturner
Date: Tue Feb 9 15:36:15 2016
New Revision: 260289
URL: http://llvm.org/viewvc/llvm-project?rev=260289&view=rev
Log:
Delete all the xfail / skip decorators for specific compilers.
Ported everything over to using expectedFailureAll.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/decorators.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStdStringFunction.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/iterator/TestDataFormatterStdIterator.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/map/TestDataFormatterStdMap.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/vbool/TestDataFormatterStdVBool.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/vector/TestDataFormatterStdVector.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/typedef_array/TestTypedefArray.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/step-avoids-no-debug/TestStepNoDebug.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_completion/TestTypeCompletion.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/auto/TestCPPAuto.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/char1632_t/TestChar1632T.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/rvalue-references/TestRvalueReferences.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestSTL.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/this/TestCPPThis.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiGdbSetShowPrint.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=260289&r1=260288&r2=260289&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Tue Feb 9 15:36:15
2016
@@ -300,22 +300,6 @@ def expectedFailureDwo(bugnumber=None):
def expectedFailureDsym(bugnumber=None):
return expectedFailureAll(bugnumber=bugnumber, debug_info="dsym")
-def expectedFailureCompiler(compiler, compiler_version=None, bugnumber=None):
-if compiler_version is None:
-compiler_version=['=', None]
-return expectedFailureAll(bugnumber=bugnumber, compiler=compiler,
compiler_version=compiler_version)
-
-# to XFAIL a specific clang versions, try this
-# @expectedFailureClang('bugnumber', ['<=', '3.4'])
-def expectedFailureClang(bugnumber=None, compiler_version=None):
-return expectedFailureCompiler('clang', compiler_version, bugnumber)
-
-def expectedFailureGcc(bugnumber=None, compiler_version=None):
-return expectedFailureCompiler('gcc', compiler_version, bugnumber)
-
-def expectedFailureIcc(bugnumber=None):
-return expectedFailureCompiler('icc', None, bugnumber)
-
def expectedFailureOS(oslist, bugnumber=None, compilers=None, debug_info=None,
archs=None):
return expectedFailureAll(oslist=oslist, bugnumber=bugnumber,
compiler=compilers, archs=archs, debug_info=debug_info)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStdStringFunction.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStdStringFunction.py?rev=260289&r1=260288&r2=260289&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStdStringFunction.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStdStringFunction.py
Tue Feb 9 15:36:15 2016
@@ -22,7 +22,7 @@ class ExprCommandCallFunctionTestCase(Te
self.line = line_number('main.cpp',
'// Please test these expressions while
stopped at this line:')
-@expectedFailureIcc # llvm.org/pr14437, fails with ICC 13.1
+@expectedFailureAll(compiler="icc", bugnumber="llvm.org/pr14437, fails
w
[Lldb-commits] [lldb] r260291 - Remove skipIf decorators.
Author: zturner
Date: Tue Feb 9 15:36:32 2016
New Revision: 260291
URL: http://llvm.org/viewvc/llvm-project?rev=260291&view=rev
Log:
Remove skipIf decorators.
These were supposed to have been removed in a previous patch,
but I missed them.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/decorators.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/TestDataFormatterLibcxxListLoop.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/multimap/TestDataFormatterLibccMultiMap.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/multiset/TestDataFormatterLibcxxMultiSet.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/string/TestDataFormatterLibcxxString.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/unordered/TestDataFormatterUnordered.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vbool/TestDataFormatterLibcxxVBool.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/anonymous/TestAnonymous.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.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=260291&r1=260290&r2=260291&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Tue Feb 9 15:36:32
2016
@@ -509,15 +509,6 @@ def skipUnlessPlatform(oslist):
return unittest2.skipUnless(lldbplatformutil.getPlatform() in oslist,
"requires on of %s" % (", ".join(oslist)))
-
-def skipIfGcc(func):
-"""Decorate the item to skip tests that should be skipped if building with
gcc ."""
-return skipIf(compiler="gcc")(func)
-
-def skipIfIcc(func):
-"""Decorate the item to skip tests that should be skipped if building with
icc ."""
-return skipIf(compiler="icc")(func)
-
def skipIfTargetAndroid(api_levels=None, archs=None):
"""Decorator to skip tests when the target is Android.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py?rev=260291&r1=260290&r2=260291&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
Tue Feb 9 15:36:32 2016
@@ -17,7 +17,7 @@ class InitializerListTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@skipIfWindows # libc++ not ported to Windows yet
-@skipIfGcc
+@skipIf(compiler="gcc")
@expectedFailureLinux # fails on clang 3.5 and tot
def test(self):
"""Test that that file and class static variables display correctly."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py?rev=260291&r1=260290&r2=260291&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/itera
[Lldb-commits] [lldb] r260299 - Don't complete a class type just to test if it is a class. Code in CompilerType and in clang::QualType knows how to complete a type if it needs to.
Author: gclayton
Date: Tue Feb 9 16:09:26 2016
New Revision: 260299
URL: http://llvm.org/viewvc/llvm-project?rev=260299&view=rev
Log:
Don't complete a class type just to test if it is a class. Code in CompilerType
and in clang::QualType knows how to complete a type if it needs to.
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=260299&r1=260298&r2=260299&view=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
Tue Feb 9 16:09:26 2016
@@ -191,7 +191,7 @@ ItaniumABILanguageRuntime::GetDynamicTyp
type_sp = class_types.GetTypeAtIndex(i);
if (type_sp)
{
-if
(ClangASTContext::IsCXXClassType(type_sp->GetFullCompilerType ()))
+if
(ClangASTContext::IsCXXClassType(type_sp->GetForwardCompilerType()))
{
if (log)
log->Printf ("0x%16.16" PRIx64 ":
static-type = '%s' has multiple matching dynamic types, picking this one:
uid={0x%" PRIx64 "}, type-name='%s'\n",
@@ -224,7 +224,7 @@ ItaniumABILanguageRuntime::GetDynamicTyp
if (type_sp)
{
if (ClangASTContext::AreTypesSame
(in_value.GetCompilerType(),
-
type_sp->GetFullCompilerType ()))
+
type_sp->GetForwardCompilerType ()))
{
// The dynamic type we found was the same type,
// so we don't have a dynamic type here...
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260308 - Fixed many issues that were causing differing type definition issues to show up when parsing expressions.
Author: gclayton
Date: Tue Feb 9 16:36:24 2016
New Revision: 260308
URL: http://llvm.org/viewvc/llvm-project?rev=260308&view=rev
Log:
Fixed many issues that were causing differing type definition issues to show up
when parsing expressions.
1) Turns out we weren't correctly uniquing types for C++. We would search our
repository for "lldb_private::Process", but yet store just "Process" in the
unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to
complete a C++ or Objective C class. All public inquiries into the SymbolFile
go through SymbolVendor, and SymbolVendor correctly takes the module lock
before it call the SymbolFile API call, but when we let CompilerType objects
out in the wild, they can complete themselves at any time from the expression
parser, so the ValueObjects or (SBValue objects in the public API), and many
more places. So we now take the module lock when completing a type to avoid two
threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:
class A
{
void Foo(T t);
};
The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone
specialized it. This would cause a class definition for A inside a.cpp that
used a "int" and "float" overload to look like:
class A
{
void Foo(int t);
void Foo(double t);
};
And a version from b.cpp that used a "float" overload to look like:
class A
{
void Foo(float t);
};
And a version from c.cpp that use no overloads to look like:
class A
{
};
Then in an expression if you have two variables, one name "a" from a.cpp in
liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get
conflicting definitions for "A" and your expression will fail. This all stems
from the fact that DWARF _only_ emits template specializations, not generic
definitions, and they are only emitted if they are used. There are two
solutions to this:
a) When ever you run into ANY class, you must say "just because this class
doesn't have templatized member functions, it doesn't mean that any other
instances might not have any, so when ever I run into ANY class, I must parse
all compile units and parse all instances of class "A" just in case it has
member functions that are templatized.". That is really bad because it means
you always pull in ALL DWARF that contains most likely exact duplicate
definitions of the class "A" and you bloat the memory that the SymbolFileDWARF
plug-in uses in LLDB (since you pull in all DIEs from all compile units that
contain a "A" definition) uses for little value most of the time.
b) Modify DWARF to emit generic template member function definitions so
that you know from looking at any instance of class "A" wether it has template
member functions or not. In order to do this, we would have to have the ability
to correctly parse a member function template, but there is a compiler bug:
[PR 26553] C++ Debug info should reference
DW_TAG_template_type_parameter
This bugs means that not all of the info needed to correctly make a
template member function is in the DWARF. The main source of the problem is if
we have DWARF for a template instantiation for "int" like: "void
A::Foo(T)" the DWARF comes out as "void A::Foo(int)" (it doesn't
mention type "T", it resolves the type to the specialized type to "int"). But
if you actually have your function defined as " void Foo(int t)"
and you only use T for local variables inside the function call, we can't
correctly make the function prototype up in the clang::ASTContext.
So the best we can do for now we just omit all member functions that are
templatized from the class definition so that "A" never has any template member
functions. This means all defintions of "A" look like:
class A
{
};
And our expressions will work. You won't be able to call template member
fucntions in expressions (not a regression, we weren't able to do this before)
and if you are stopped in a templatized member function, we won't know that are
are in a method of class "A". All things we should fix, but we need
fixed first, followed by:
Classes should always include a template
subprogram definition, even when no template member functions are used
before we can do anything about it in LLDB.
This bug mainly fixed the following Apple radar:
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=260308&r1=260307&r2=2
Re: [Lldb-commits] [lldb] r260308 - Fixed many issues that were causing differing type definition issues to show up when parsing expressions.
Any tests for this?
On Tue, Feb 9, 2016 at 2:40 PM Greg Clayton via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: gclayton
> Date: Tue Feb 9 16:36:24 2016
> New Revision: 260308
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260308&view=rev
> Log:
> Fixed many issues that were causing differing type definition issues to
> show up when parsing expressions.
>
> 1) Turns out we weren't correctly uniquing types for C++. We would search
> our repository for "lldb_private::Process", but yet store just "Process" in
> the unique type map. Now we store things correctly and correctly unique
> types.
> 2) SymbolFileDWARF::CompleteType() can be called at any time in order to
> complete a C++ or Objective C class. All public inquiries into the
> SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the
> module lock before it call the SymbolFile API call, but when we let
> CompilerType objects out in the wild, they can complete themselves at any
> time from the expression parser, so the ValueObjects or (SBValue objects in
> the public API), and many more places. So we now take the module lock when
> completing a type to avoid two threads being in the SymbolFileDWARF at the
> same time.
> 3) If a class has a template member function like:
>
> class A
> {
>
> void Foo(T t);
> };
>
> The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone
> specialized it. This would cause a class definition for A inside a.cpp that
> used a "int" and "float" overload to look like:
> class A
> {
> void Foo(int t);
> void Foo(double t);
> };
>
> And a version from b.cpp that used a "float" overload to look like:
> class A
> {
> void Foo(float t);
> };
>
> And a version from c.cpp that use no overloads to look like:
>
> class A
> {
> };
>
> Then in an expression if you have two variables, one name "a" from
> a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will
> get conflicting definitions for "A" and your expression will fail. This all
> stems from the fact that DWARF _only_ emits template specializations, not
> generic definitions, and they are only emitted if they are used. There are
> two solutions to this:
> a) When ever you run into ANY class, you must say "just because this
> class doesn't have templatized member functions, it doesn't mean that any
> other instances might not have any, so when ever I run into ANY class, I
> must parse all compile units and parse all instances of class "A" just in
> case it has member functions that are templatized.". That is really bad
> because it means you always pull in ALL DWARF that contains most likely
> exact duplicate definitions of the class "A" and you bloat the memory that
> the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from
> all compile units that contain a "A" definition) uses for little value most
> of the time.
> b) Modify DWARF to emit generic template member function definitions
> so that you know from looking at any instance of class "A" wether it has
> template member functions or not. In order to do this, we would have to
> have the ability to correctly parse a member function template, but there
> is a compiler bug:
> [PR 26553] C++ Debug info should reference
> DW_TAG_template_type_parameter
> This bugs means that not all of the info needed to correctly make a
> template member function is in the DWARF. The main source of the problem is
> if we have DWARF for a template instantiation for "int" like: "void
> A::Foo(T)" the DWARF comes out as "void A::Foo(int)" (it doesn't
> mention type "T", it resolves the type to the specialized type to "int").
> But if you actually have your function defined as " void
> Foo(int t)" and you only use T for local variables inside the function
> call, we can't correctly make the function prototype up in the
> clang::ASTContext.
>
> So the best we can do for now we just omit all member functions that
> are templatized from the class definition so that "A" never has any
> template member functions. This means all defintions of "A" look like:
>
> class A
> {
> };
>
> And our expressions will work. You won't be able to call template
> member fucntions in expressions (not a regression, we weren't able to do
> this before) and if you are stopped in a templatized member function, we
> won't know that are are in a method of class "A". All things we should fix,
> but we need fixed first, followed by:
>
> Classes should always include a template
> subprogram definition, even when no template member functions are used
>
> before we can do anything about it in LLDB.
>
> This bug mainly fixed the following Apple radar:
>
>
>
>
> Modified:
> lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
> lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
> lldb/trunk/source/Plugins/SymbolF
Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
krytarowski added a comment. Just in case someone will be quicker, new version against revamped CMake dirs is in pkgsrc-wip/lldb-git Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16902: Add status for LLDB on Windows to status.html.
amccarth added a comment. Friendly ping. http://reviews.llvm.org/D16902 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r260308 - Fixed many issues that were causing differing type definition issues to show up when parsing expressions.
Not yet, but I will try to reduce one down. The best I have right now is to
debug clang, set a breakpoint at "Sema::SelectBestMethod" and then run "p Sel"
when you hit the breakpoint. This is of course only by running with a file:
lldb -- "/tmp/local/clang/install/bin/clang-3.8" -cc1 -triple
arm64-apple-ios5.0.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration
-fsyntax-only -disable-free -main-file-name ios10.mi -mrelocation-model pic
-pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -target-cpu
cyclone -target-feature +neon -target-feature +crc -target-feature +crypto
-target-feature +zcm -target-feature +zcz -target-abi darwinpcs
-target-linker-version 262.4 -v -dwarf-column-info -resource-dir
/tmp/local/clang/install/bin/../lib/clang/3.8.0 -fdebug-compilation-dir /tmp
-ferror-limit 19 -fmessage-length 80 -stack-protector 1
-fallow-half-arguments-and-returns -fblocks -fobjc-runtime=ios-5.0.0
-fencode-extended-block-signature -fobjc-exceptions -fexceptions
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -x
objective-c-cpp-output ios10.mi
So not a very reduced test case. I will work on getting one in ASAP but I would
like it to be more self contained and controlled. The expression also takes way
too long (30-90 seconds) because of the changes that were previously added
(revision 247746) that parse everything in a decl context. If that proves to be
what is slowing down expressions, I will need to do something about it as it is
affecting our expression performance.
So stay tuned, I'll follow up with a test soon.
> On Feb 9, 2016, at 2:48 PM, Zachary Turner wrote:
>
> Any tests for this?
>
> On Tue, Feb 9, 2016 at 2:40 PM Greg Clayton via lldb-commits
> wrote:
> Author: gclayton
> Date: Tue Feb 9 16:36:24 2016
> New Revision: 260308
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260308&view=rev
> Log:
> Fixed many issues that were causing differing type definition issues to show
> up when parsing expressions.
>
> 1) Turns out we weren't correctly uniquing types for C++. We would search our
> repository for "lldb_private::Process", but yet store just "Process" in the
> unique type map. Now we store things correctly and correctly unique types.
> 2) SymbolFileDWARF::CompleteType() can be called at any time in order to
> complete a C++ or Objective C class. All public inquiries into the SymbolFile
> go through SymbolVendor, and SymbolVendor correctly takes the module lock
> before it call the SymbolFile API call, but when we let CompilerType objects
> out in the wild, they can complete themselves at any time from the expression
> parser, so the ValueObjects or (SBValue objects in the public API), and many
> more places. So we now take the module lock when completing a type to avoid
> two threads being in the SymbolFileDWARF at the same time.
> 3) If a class has a template member function like:
>
> class A
> {
>
> void Foo(T t);
> };
>
> The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone
> specialized it. This would cause a class definition for A inside a.cpp that
> used a "int" and "float" overload to look like:
> class A
> {
> void Foo(int t);
> void Foo(double t);
> };
>
> And a version from b.cpp that used a "float" overload to look like:
> class A
> {
> void Foo(float t);
> };
>
> And a version from c.cpp that use no overloads to look like:
>
> class A
> {
> };
>
> Then in an expression if you have two variables, one name "a" from a.cpp
> in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get
> conflicting definitions for "A" and your expression will fail. This all stems
> from the fact that DWARF _only_ emits template specializations, not generic
> definitions, and they are only emitted if they are used. There are two
> solutions to this:
> a) When ever you run into ANY class, you must say "just because this
> class doesn't have templatized member functions, it doesn't mean that any
> other instances might not have any, so when ever I run into ANY class, I must
> parse all compile units and parse all instances of class "A" just in case it
> has member functions that are templatized.". That is really bad because it
> means you always pull in ALL DWARF that contains most likely exact duplicate
> definitions of the class "A" and you bloat the memory that the
> SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all
> compile units that contain a "A" definition) uses for little value most of
> the time.
> b) Modify DWARF to emit generic template member function definitions so
> that you know from looking at any instance of class "A" wether it has
> template member functions or not. In order to do this, we would have to have
> the ability to correctly parse a member function template, but there is
[Lldb-commits] [lldb] r260322 - Added code that was commented out during testing to stops template member functions from being added to class definitions (see revision 260308 for details).
Author: gclayton
Date: Tue Feb 9 17:25:54 2016
New Revision: 260322
URL: http://llvm.org/viewvc/llvm-project?rev=260322&view=rev
Log:
Added code that was commented out during testing to stops template member
functions from being added to class definitions (see revision 260308 for
details).
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=260322&r1=260321&r2=260322&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Tue Feb
9 17:25:54 2016
@@ -1214,11 +1214,11 @@ DWARFASTParserClang::ParseTypeFromDWARF
// that may or may not include these member functions and
this means one class won't match another
// class definition and it affects our ability to use a
class in the clang expression parser. So
// for the greater good, we currently must not allow any
template member functions in a class definition.
-//if (is_cxx_method && has_template_params)
-//{
-//ignore_containing_context = true;
-//is_cxx_method = false;
-//}
+if (is_cxx_method && has_template_params)
+{
+ignore_containing_context = true;
+is_cxx_method = false;
+}
// clang_type will get the function prototype clang type
after this call
clang_type = m_ast.CreateFunctionType (return_clang_type,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260326 - Change `CoreTests` to LLDBCoreTests to avoid name clash.
Author: zturner Date: Tue Feb 9 17:45:21 2016 New Revision: 260326 URL: http://llvm.org/viewvc/llvm-project?rev=260326&view=rev Log: Change `CoreTests` to LLDBCoreTests to avoid name clash. lld was already using a target named CoreTests so CMake was erroring due to this conflict. Modified: lldb/trunk/unittests/Core/CMakeLists.txt Modified: lldb/trunk/unittests/Core/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Core/CMakeLists.txt?rev=260326&r1=260325&r2=260326&view=diff == --- lldb/trunk/unittests/Core/CMakeLists.txt (original) +++ lldb/trunk/unittests/Core/CMakeLists.txt Tue Feb 9 17:45:21 2016 @@ -1,3 +1,3 @@ -add_lldb_unittest(CoreTests +add_lldb_unittest(LLDBCoreTests ScalarTest.cpp ) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260328 - Add status for LLDB on Windows to status.html.
Author: amccarth Date: Tue Feb 9 17:52:57 2016 New Revision: 260328 URL: http://llvm.org/viewvc/llvm-project?rev=260328&view=rev Log: Add status for LLDB on Windows to status.html. Differential Revision: http://reviews.llvm.org/D16902 Modified: lldb/trunk/www/status.html Modified: lldb/trunk/www/status.html URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/status.html?rev=260328&r1=260327&r2=260328&view=diff == --- lldb/trunk/www/status.html (original) +++ lldb/trunk/www/status.html Tue Feb 9 17:52:57 2016 @@ -44,23 +44,32 @@ LLDB on FreeBSD lags behind the Linux implementation but is improving rapidly. For more details, see the Features by OS section below. +Windows Status + + LLDB on Windows is still under development, but already useful for i386 +programs (x86_64 untested) built with DWARF debug information, including postmortem +analysis of minidumps. +For more details, see the Features by OS section below. + Features by OS The table below shows a summary of the features that are available on several platforms. In addition to Linux and Mac OS X, LLDB is also -known to work on FreeBSD. Windows and NetBSD support is under development. +known to work on FreeBSD. NetBSD support is under development. Feature FreeBSD(x86_64) Linux(x86_64) Mac OS X (i386/x86_64 and ARM/Thumb) +Windows (i386) Backtracing OK OK OK +OK Breakpoints @@ -74,6 +83,7 @@ OK OK OK +OK C++11: @@ -85,42 +95,49 @@ OK OK OK +Unknown Commandline lldb tool OK OK OK +OK Core file debugging OK (ELF) OK (ELF) OK (MachO) +OK (Minidump) Debugserver (remote debugging) Not ported Not ported OK +Not ported Disassembly OK OK OK +OK Expression evaluation Unknown Works with some bugs OK +Works with some bugs JIT debugging Unknown Symbolic debugging only Untested +No Objective-C 2.0: @@ -138,6 +155,7 @@ Unknown Not applicable OK +Not applicable Process control @@ -153,12 +171,14 @@ Works, with some bugs OK (except exec*) OK +
Re: [Lldb-commits] [PATCH] D16902: Add status for LLDB on Windows to status.html.
This revision was automatically updated to reflect the committed changes. Closed by commit rL260328: Add status for LLDB on Windows to status.html. (authored by amccarth). Changed prior to commit: http://reviews.llvm.org/D16902?vs=46964&id=47390#toc Repository: rL LLVM http://reviews.llvm.org/D16902 Files: lldb/trunk/www/status.html Index: lldb/trunk/www/status.html === --- lldb/trunk/www/status.html +++ lldb/trunk/www/status.html @@ -44,23 +44,32 @@ LLDB on FreeBSD lags behind the Linux implementation but is improving rapidly. For more details, see the Features by OS section below. +Windows Status + + LLDB on Windows is still under development, but already useful for i386 +programs (x86_64 untested) built with DWARF debug information, including postmortem +analysis of minidumps. +For more details, see the Features by OS section below. + Features by OS The table below shows a summary of the features that are available on several platforms. In addition to Linux and Mac OS X, LLDB is also -known to work on FreeBSD. Windows and NetBSD support is under development. +known to work on FreeBSD. NetBSD support is under development. Feature FreeBSD(x86_64) Linux(x86_64) Mac OS X (i386/x86_64 and ARM/Thumb) +Windows (i386) Backtracing OK OK OK +OK Breakpoints @@ -74,6 +83,7 @@ OK OK OK +OK C++11: @@ -85,42 +95,49 @@ OK OK OK +Unknown Commandline lldb tool OK OK OK +OK Core file debugging OK (ELF) OK (ELF) OK (MachO) +OK (Minidump) Debugserver (remote debugging) Not ported Not ported OK +Not ported Disassembly OK OK OK +OK Expression evaluation Unknown Works with some bugs OK +Works with some bugs JIT debugging Unknown Symbolic debugging only Untested +No Objective-C 2.0: @@ -138,6 +155,7 @@ Unknown Not applicable OK +Not applicable Process control @@ -153,12 +171,14 @@ Works, with some bugs OK (except exec*) OK +OK Pu
[Lldb-commits] [lldb] r260330 - Remove FreeBSD failure decorator from TestCppIncompleteTypes
Author: emaste
Date: Tue Feb 9 18:03:52 2016
New Revision: 260330
URL: http://llvm.org/viewvc/llvm-project?rev=260330&view=rev
Log:
Remove FreeBSD failure decorator from TestCppIncompleteTypes
CFLAGS is now being set correctly to pass -flimit-debug-info or
-fno-limit-debug-info on FreeBSD. I'm not sure which change is
responsible for the fix, though.
llvm.org/pr25626
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py?rev=260330&r1=260329&r2=260330&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py
Tue Feb 9 18:03:52 2016
@@ -7,7 +7,6 @@ class TestCppIncompleteTypes(TestBase):
mydir = TestBase.compute_mydir(__file__)
-@expectedFailureFreeBSD("llvm.org/pr25626 test executable not built
correctly on FreeBSD")
@skipIf(compiler="gcc")
def test_limit_debug_info(self):
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260331 - Don't dereference the first element of an empty container.
Author: amccarth Date: Tue Feb 9 18:06:50 2016 New Revision: 260331 URL: http://llvm.org/viewvc/llvm-project?rev=260331&view=rev Log: Don't dereference the first element of an empty container. Modified: lldb/trunk/source/Symbol/Symtab.cpp Modified: lldb/trunk/source/Symbol/Symtab.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/Symtab.cpp?rev=260331&r1=260330&r2=260331&view=diff == --- lldb/trunk/source/Symbol/Symtab.cpp (original) +++ lldb/trunk/source/Symbol/Symtab.cpp Tue Feb 9 18:06:50 2016 @@ -56,7 +56,7 @@ Symtab::Resize(size_t count) // Clients should grab the mutex from this symbol table and lock it manually // when calling this function to avoid performance issues. m_symbols.resize (count); -return &m_symbols[0]; +return m_symbols.empty() ? nullptr : &m_symbols[0]; } uint32_t ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260345 - Add a missing break.
Author: jingham Date: Tue Feb 9 19:33:58 2016 New Revision: 260345 URL: http://llvm.org/viewvc/llvm-project?rev=260345&view=rev Log: Add a missing break. Modified: lldb/trunk/tools/debugserver/source/debugserver.cpp Modified: lldb/trunk/tools/debugserver/source/debugserver.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/debugserver.cpp?rev=260345&r1=260344&r2=260345&view=diff == --- lldb/trunk/tools/debugserver/source/debugserver.cpp (original) +++ lldb/trunk/tools/debugserver/source/debugserver.cpp Tue Feb 9 19:33:58 2016 @@ -1080,7 +1080,7 @@ main (int argc, char *argv[]) case 'K': g_detach_on_error = false; - +break; case 'W': if (optarg && optarg[0]) working_dir.assign(optarg); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r260349 - Change lldb.value.__int__() so that it takes into account the signedness of the value being cast to return a Python number with the proper value
Author: enrico
Date: Tue Feb 9 20:12:42 2016
New Revision: 260349
URL: http://llvm.org/viewvc/llvm-project?rev=260349&view=rev
Log:
Change lldb.value.__int__() so that it takes into account the signedness of the
value being cast to return a Python number with the proper value
The explicit APIs on SBValue obviously remain if one wants to be explicit in
intent, or override this guess, but since __int__() has to pick one, an
educated guess is definitely better than than always going to signed regardless
Fixes rdar://24556976
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/value/main.c
lldb/trunk/scripts/Python/python-extensions.swig
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py?rev=260349&r1=260348&r2=260349&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
Tue Feb 9 20:12:42 2016
@@ -134,3 +134,12 @@ class ValueAPITestCase(TestBase):
val_a = target.EvaluateExpression('a')
self.assertTrue(val_s.GetChildMemberWithName('a').AddressOf(),
VALID_VARIABLE)
self.assertTrue(val_a.Cast(val_i.GetType()).AddressOf(),
VALID_VARIABLE)
+
+self.assertTrue(int(lldb.value(frame0.FindVariable('uinthex'))) ==
3768803088, 'uinthex == 3768803088')
+self.assertTrue(int(lldb.value(frame0.FindVariable('sinthex'))) ==
-526164208, 'sinthex == -526164208')
+
+self.assertTrue(frame0.FindVariable('uinthex').GetValueAsUnsigned() ==
3768803088, 'unsigned uinthex == 3768803088')
+self.assertTrue(frame0.FindVariable('sinthex').GetValueAsUnsigned() ==
3768803088, 'unsigned sinthex == 3768803088')
+
+self.assertTrue(frame0.FindVariable('uinthex').GetValueAsSigned() ==
-526164208, 'signed uinthex == -526164208')
+self.assertTrue(frame0.FindVariable('sinthex').GetValueAsSigned() ==
-526164208, 'signed sinthex == -526164208')
Modified: lldb/trunk/packages/Python/lldbsuite/test/python_api/value/main.c
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/value/main.c?rev=260349&r1=260348&r2=260349&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/value/main.c (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/value/main.c Tue Feb
9 20:12:42 2016
@@ -7,6 +7,7 @@
//
//===--===//
#include
+#include
// This simple program is to test the lldb Python API
SBValue.GetChildAtIndex().
@@ -38,6 +39,9 @@ struct MyStruct
int main (int argc, char const *argv[])
{
+uint32_t uinthex = 0xE0A35F10;
+int32_t sinthex = 0xE0A35F10;
+
int i;
MyInt a = 12345;
struct MyStruct s = { 11, 22 };
Modified: lldb/trunk/scripts/Python/python-extensions.swig
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-extensions.swig?rev=260349&r1=260348&r2=260349&view=diff
==
--- lldb/trunk/scripts/Python/python-extensions.swig (original)
+++ lldb/trunk/scripts/Python/python-extensions.swig Tue Feb 9 20:12:42 2016
@@ -1024,11 +1024,13 @@ class value(object):
return complex (int(self))
def __int__(self):
+is_num,is_sign =
is_numeric_type(self.sbvalue.GetType().GetCanonicalType().GetBasicType())
+if is_num and not is_sign: return self.sbvalue.GetValueAsUnsigned()
return self.sbvalue.GetValueAsSigned()
-
+
def __long__(self):
-return self.sbvalue.GetValueAsSigned()
-
+return self.__int__()
+
def __float__(self):
return float (self.sbvalue.GetValueAsSigned())
@@ -1084,4 +1086,47 @@ class SBSyntheticValueProvider(object):
return False
+%}
+
+%pythoncode %{
+
+# given an lldb.SBBasicType it returns a tuple
+# (is_numeric, is_signed)
+# the value of is_signed is undefined if is_numeric == false
+def is_numeric_type(basic_type):
+if basic_type == eBasicTypeInvalid: return (False,False)
+if basic_type == eBasicTypeVoid: return (False,False)
+if basic_type == eBasicTypeChar: return (True,False)
+if basic_type == eBasicTypeSignedChar: return (True,True)
+if basic_type == eBasicTypeUnsignedChar: return (True,False)
+if basic_type == eBasicTypeWChar: return (True,False)
+if basic_type == eBasicTypeSignedWChar: return (True,True)
+if basic_type == eBasicTypeUnsignedWChar: return (True,False)
+if basic_type == eBasicTypeChar16: return
[Lldb-commits] [lldb] r260352 - This is an idea to make "thread step-in --target" work for the common
Author: jingham
Date: Tue Feb 9 21:25:24 2016
New Revision: 260352
URL: http://llvm.org/viewvc/llvm-project?rev=260352&view=rev
Log:
This is an idea to make "thread step-in --target" work for the common
case where you have:
1 ->foo (bar(),
2baz(),
3lala());
4
You are sitting on line 1, and want to step into foo, but not bar, baz & lala.
Unfortunately
there are line table entries for lines 1-3, and lldb doesn't know anything
about the nesting
of statement in these lines. So we'll have to use the user's intelligence...
This patch adds:
(lldb) thread step-in -t foo --end-line 4
That tells lldb to keep stepping in till line 4, but stop if you step into foo.
I think I would
remember to use this when faced with some of the long gnarly call sequences in
lldb. But there
might be ways I haven't thought of to make it more convenient. Jason suggests
having "end" as a
special token for --end-line which just means keep going to the end of the
function, I really want
to get into this thing...
There should be an SB API and tests, which will come if this seems useful.
Modified:
lldb/trunk/source/Commands/CommandObjectThread.cpp
Modified: lldb/trunk/source/Commands/CommandObjectThread.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectThread.cpp?rev=260352&r1=260351&r2=260352&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectThread.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectThread.cpp Tue Feb 9 21:25:24 2016
@@ -386,7 +386,7 @@ public:
{
m_step_count = StringConvert::ToUInt32(option_arg,
UINT32_MAX, 0);
if (m_step_count == UINT32_MAX)
- error.SetErrorStringWithFormat ("invalid ignore count
'%s'", option_arg);
+ error.SetErrorStringWithFormat ("invalid step count
'%s'", option_arg);
break;
}
break;
@@ -403,6 +403,16 @@ public:
}
break;
+case 'e':
+{
+uint32_t tmp_end_line =
StringConvert::ToUInt32(option_arg, UINT32_MAX, 0);
+if (tmp_end_line == UINT32_MAX)
+ error.SetErrorStringWithFormat ("invalid end line
number '%s'", option_arg);
+else
+m_end_line = tmp_end_line;
+break;
+}
+break;
case 'r':
{
m_avoid_regexp.clear();
@@ -441,6 +451,7 @@ public:
m_step_in_target.clear();
m_class_name.clear();
m_step_count = 1;
+m_end_line = LLDB_INVALID_LINE_NUMBER;
}
const OptionDefinition*
@@ -461,6 +472,7 @@ public:
std::string m_step_in_target;
std::string m_class_name;
uint32_t m_step_count;
+uint32_t m_end_line;
};
CommandObjectThreadStepWithTypeAndScope (CommandInterpreter &interpreter,
@@ -559,6 +571,14 @@ protected:
}
}
+if (m_options.m_end_line != LLDB_INVALID_LINE_NUMBER
+&& m_step_type != eStepTypeInto)
+{
+result.AppendErrorWithFormat("end line option is only valid for
step into");
+result.SetStatus(eReturnStatusFailed);
+return false;
+}
+
const bool abort_other_plans = false;
const lldb::RunMode stop_other_threads = m_options.m_run_mode;
@@ -586,8 +606,70 @@ protected:
if (frame->HasDebugInformation ())
{
+AddressRange range =
frame->GetSymbolContext(eSymbolContextEverything).line_entry.range;
+if (m_options.m_end_line != LLDB_INVALID_LINE_NUMBER)
+{
+SymbolContext sc =
frame->GetSymbolContext(eSymbolContextEverything);
+if (sc.line_entry.line > m_options.m_end_line)
+{
+result.AppendErrorWithFormat("end line option %d must
be after the current line: %d",
+ m_options.m_end_line,
+ sc.line_entry.line);
+result.SetStatus(eReturnStatusFailed);
+return false;
+}
+
+CompileUnit *cu = sc.comp_unit;
+uint32_t line_index = 0;
+bool found = false;
+while (1)
+{
+LineEntry this_line;
+line_index = cu->FindLineEntry(line_index,
sc.line_entry.line, nullptr, false, &this_line);
+if (line_index == UINT32_MAX)
+break;
+
Re: [Lldb-commits] [lldb] r260352 - This is an idea to make "thread step-in --target" work for the common
Seems like kind of an obscure command. Why not just set a one-shot
breakpoint on foo by name, then continue, so that the first time the
breakpoint hits it gets removed.
Also what happens if bar() calls foo()?
On Tue, Feb 9, 2016 at 7:29 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: jingham
> Date: Tue Feb 9 21:25:24 2016
> New Revision: 260352
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260352&view=rev
> Log:
> This is an idea to make "thread step-in --target" work for the common
> case where you have:
>
> 1 ->foo (bar(),
> 2baz(),
> 3lala());
> 4
>
> You are sitting on line 1, and want to step into foo, but not bar, baz &
> lala. Unfortunately
> there are line table entries for lines 1-3, and lldb doesn't know anything
> about the nesting
> of statement in these lines. So we'll have to use the user's
> intelligence... This patch adds:
>
> (lldb) thread step-in -t foo --end-line 4
>
> That tells lldb to keep stepping in till line 4, but stop if you step into
> foo. I think I would
> remember to use this when faced with some of the long gnarly call
> sequences in lldb. But there
> might be ways I haven't thought of to make it more convenient. Jason
> suggests having "end" as a
> special token for --end-line which just means keep going to the end of the
> function, I really want
> to get into this thing...
>
> There should be an SB API and tests, which will come if this seems useful.
>
> Modified:
> lldb/trunk/source/Commands/CommandObjectThread.cpp
>
> Modified: lldb/trunk/source/Commands/CommandObjectThread.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectThread.cpp?rev=260352&r1=260351&r2=260352&view=diff
>
> ==
> --- lldb/trunk/source/Commands/CommandObjectThread.cpp (original)
> +++ lldb/trunk/source/Commands/CommandObjectThread.cpp Tue Feb 9 21:25:24
> 2016
> @@ -386,7 +386,7 @@ public:
> {
> m_step_count = StringConvert::ToUInt32(option_arg,
> UINT32_MAX, 0);
> if (m_step_count == UINT32_MAX)
> - error.SetErrorStringWithFormat ("invalid ignore
> count '%s'", option_arg);
> + error.SetErrorStringWithFormat ("invalid step
> count '%s'", option_arg);
> break;
> }
> break;
> @@ -403,6 +403,16 @@ public:
> }
> break;
>
> +case 'e':
> +{
> +uint32_t tmp_end_line =
> StringConvert::ToUInt32(option_arg, UINT32_MAX, 0);
> +if (tmp_end_line == UINT32_MAX)
> + error.SetErrorStringWithFormat ("invalid end line
> number '%s'", option_arg);
> +else
> +m_end_line = tmp_end_line;
> +break;
> +}
> +break;
> case 'r':
> {
> m_avoid_regexp.clear();
> @@ -441,6 +451,7 @@ public:
> m_step_in_target.clear();
> m_class_name.clear();
> m_step_count = 1;
> +m_end_line = LLDB_INVALID_LINE_NUMBER;
> }
>
> const OptionDefinition*
> @@ -461,6 +472,7 @@ public:
> std::string m_step_in_target;
> std::string m_class_name;
> uint32_t m_step_count;
> +uint32_t m_end_line;
> };
>
> CommandObjectThreadStepWithTypeAndScope (CommandInterpreter
> &interpreter,
> @@ -559,6 +571,14 @@ protected:
> }
> }
>
> +if (m_options.m_end_line != LLDB_INVALID_LINE_NUMBER
> +&& m_step_type != eStepTypeInto)
> +{
> +result.AppendErrorWithFormat("end line option is only valid
> for step into");
> +result.SetStatus(eReturnStatusFailed);
> +return false;
> +}
> +
> const bool abort_other_plans = false;
> const lldb::RunMode stop_other_threads = m_options.m_run_mode;
>
> @@ -586,8 +606,70 @@ protected:
>
> if (frame->HasDebugInformation ())
> {
> +AddressRange range =
> frame->GetSymbolContext(eSymbolContextEverything).line_entry.range;
> +if (m_options.m_end_line != LLDB_INVALID_LINE_NUMBER)
> +{
> +SymbolContext sc =
> frame->GetSymbolContext(eSymbolContextEverything);
> +if (sc.line_entry.line > m_options.m_end_line)
> +{
> +result.AppendErrorWithFormat("end line option %d
> must be after the current line: %d",
> + m_options.m_end_line,
> + sc.line_entry.line);
> +result.SetStatus(eReturnStatusFailed);
> +return fa
Re: [Lldb-commits] [PATCH] D17022: [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
bhushan updated this revision to Diff 47422.
bhushan added a comment.
Addresses review comments.
Used local variables instead of calling accessors each time.
Repository:
rL LLVM
http://reviews.llvm.org/D17022
Files:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -175,28 +175,78 @@
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
+ArchSpec target_arch;
+if (target_sp)
+target_arch = target_sp->GetArchitecture();
+
+const auto target_machine = target_arch.GetMachine();
+
// TODO: figure out what to really do when we don't have a valid target.
// Sometimes this will be ok to just use the host target triple (when we
// evaluate say "2+3", but other expressions like breakpoint conditions
// and other things that _are_ target specific really shouldn't just be
// using the host triple. This needs to be fixed in a better way.
-if (target_sp && target_sp->GetArchitecture().IsValid())
+if (target_sp && target_arch.IsValid())
{
-std::string triple = target_sp->GetArchitecture().GetTriple().str();
+std::string triple = target_arch.GetTriple().str();
m_compiler->getTargetOpts().Triple = triple;
}
else
{
m_compiler->getTargetOpts().Triple =
llvm::sys::getDefaultTargetTriple();
}
-if (target_sp->GetArchitecture().GetMachine() == llvm::Triple::x86 ||
-target_sp->GetArchitecture().GetMachine() == llvm::Triple::x86_64)
+if (target_machine == llvm::Triple::x86 ||
+target_machine == llvm::Triple::x86_64)
{
m_compiler->getTargetOpts().Features.push_back("+sse");
m_compiler->getTargetOpts().Features.push_back("+sse2");
}
+if (target_machine == llvm::Triple::mips ||
+target_machine == llvm::Triple::mipsel ||
+target_machine == llvm::Triple::mips64 ||
+target_machine == llvm::Triple::mips64el)
+{
+std::string cpu;
+switch (target_arch.GetCore())
+{
+case ArchSpec::eCore_mips32:
+case ArchSpec::eCore_mips32el:
+cpu = "mips32"; break;
+case ArchSpec::eCore_mips32r2:
+case ArchSpec::eCore_mips32r2el:
+cpu = "mips32r2"; break;
+case ArchSpec::eCore_mips32r3:
+case ArchSpec::eCore_mips32r3el:
+cpu = "mips32r3"; break;
+case ArchSpec::eCore_mips32r5:
+case ArchSpec::eCore_mips32r5el:
+cpu = "mips32r5"; break;
+case ArchSpec::eCore_mips32r6:
+case ArchSpec::eCore_mips32r6el:
+cpu = "mips32r6"; break;
+case ArchSpec::eCore_mips64:
+case ArchSpec::eCore_mips64el:
+cpu = "mips64"; break;
+case ArchSpec::eCore_mips64r2:
+case ArchSpec::eCore_mips64r2el:
+cpu = "mips64r2"; break;
+case ArchSpec::eCore_mips64r3:
+case ArchSpec::eCore_mips64r3el:
+cpu = "mips64r3"; break;
+case ArchSpec::eCore_mips64r5:
+case ArchSpec::eCore_mips64r5el:
+cpu = "mips64r5"; break;
+case ArchSpec::eCore_mips64r6:
+case ArchSpec::eCore_mips64r6el:
+cpu = "mips64r6"; break;
+default:
+cpu = "generic"; break;
+}
+m_compiler->getTargetOpts().CPU = cpu;
+}
+
// Any arm32 iOS environment, but not on arm64
if (m_compiler->getTargetOpts().Triple.find("arm64") == std::string::npos
&&
m_compiler->getTargetOpts().Triple.find("arm") != std::string::npos &&
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -175,28 +175,78 @@
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
+ArchSpec target_arch;
+if (target_sp)
+target_arch = target_sp->GetArchitecture();
+
+const auto target_machine = target_arch.GetMachine();
+
// TODO: figure out what to really do when we don't have a valid target.
// Sometimes this will be ok to just use the host target triple (when we
// evaluate say "2+3", but other expressions like breakpoint conditions
// and other things that _are_ target specific really shouldn't just be
// using the host triple. This needs to be fixed in a better way.
-if (target_sp && target_sp->GetArchitecture().IsValid())
+if (target_sp && target_arch.IsValid())
{
-std::string triple = target_sp->GetArchitecture().GetTriple().str();
+std::string triple = target_arch.GetTriple().st
Re: [Lldb-commits] [PATCH] D17022: [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
zturner added a subscriber: zturner.
zturner requested changes to this revision.
zturner added a reviewer: zturner.
This revision now requires changes to proceed.
Comment at:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:206-210
@@ -199,1 +205,7 @@
+if (target_machine == llvm::Triple::mips ||
+target_machine == llvm::Triple::mipsel ||
+target_machine == llvm::Triple::mips64 ||
+target_machine == llvm::Triple::mips64el)
+{
+std::string cpu;
I don't like this big switch statement. This logic should be somewhere else,
for example on the `ArchSpec` class. And it should handle not just mips, but
everything.
Repository:
rL LLVM
http://reviews.llvm.org/D17022
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16840: [LLDB][MIPS] Generalise MIPS arch names
This revision was automatically updated to reflect the committed changes.
Closed by commit rL260362: [LLDB][MIPS] Generalise MIPS arch names (authored by
mohit.bhakkad).
Changed prior to commit:
http://reviews.llvm.org/D16840?vs=46919&id=47423#toc
Repository:
rL LLVM
http://reviews.llvm.org/D16840
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
@@ -22,7 +22,7 @@
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
@expectedFailureAndroid("llvm.org/pr24497", archs=['arm', 'aarch64'])
-@expectedFailureAll(archs=['mips', 'mipsel', 'mips64', 'mips64el'])#
IO error due to breakpoint at invalid address
+@expectedFailureAll(triple = re.compile('^mips'))# IO error due to
breakpoint at invalid address
def test_step_inst_with(self):
"""Test thread creation during step-inst handling."""
self.build(dictionary=self.getBuildFlags())
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
@@ -74,7 +74,7 @@
# Most of the MIPS boards provide only one H/W watchpoints, and S/W
watchpoints are not supported yet
arch = self.getArchitecture()
-if arch in ['mips', 'mipsel', 'mips64', 'mips64el']:
+if re.match("^mips",arch):
self.runCmd("watchpoint delete 1")
# resolve_location=True, read=False, write=True
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
@@ -32,7 +32,7 @@
@expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not
supported
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24446:
WINDOWS XFAIL TRIAGE - Watchpoints not supported on Windows")
-@expectedFailureAll(archs=['mips', 'mipsel', 'mips64', 'mips64el']) # Most
of the MIPS boards provide only one H/W watchpoints, and S/W watchpoints are
not supported yet
+@expectedFailureAll(triple = re.compile('^mips')) # Most of the MIPS
boards provide only one H/W watchpoints, and S/W watchpoints are not supported
yet
@skipIfDarwin
def test_hello_watchlocation(self):
"""Test watching a location with '-s size' option."""
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
@@ -22,7 +22,7 @@
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
@expectedFailureAndroid("llvm.org/pr24497", archs=['arm', 'aarch64'])
-@expectedFailureAll(archs=['mips', 'mipsel', 'mips64', 'mips64el'])# IO error due to breakpoint at invalid address
+@expectedFailureAll(triple = re.compile('^mips'))# IO error due to breakpoint at invalid address
def test_step_inst_with(self):
"""Test thread creation during step-inst handling."""
self.build(dictionary=self.getBuildFlags())
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
@@ -74,7 +74,7 @@
# Most of the MIPS boards provide only one
[Lldb-commits] [lldb] r260362 - [LLDB][MIPS] Generalise MIPS arch names
Author: mohit.bhakkad
Date: Wed Feb 10 00:58:13 2016
New Revision: 260362
URL: http://llvm.org/viewvc/llvm-project?rev=260362&view=rev
Log:
[LLDB][MIPS] Generalise MIPS arch names
Patch by Nitesh Jain
Reviewers: clayborg, jaydeep.
Subscribers: zturner, bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D16840
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py?rev=260362&r1=260361&r2=260362&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
Wed Feb 10 00:58:13 2016
@@ -22,7 +22,7 @@ class CreateDuringStepTestCase(TestBase)
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
@expectedFailureAndroid("llvm.org/pr24497", archs=['arm', 'aarch64'])
-@expectedFailureAll(archs=['mips', 'mipsel', 'mips64', 'mips64el'])#
IO error due to breakpoint at invalid address
+@expectedFailureAll(triple = re.compile('^mips'))# IO error due to
breakpoint at invalid address
def test_step_inst_with(self):
"""Test thread creation during step-inst handling."""
self.build(dictionary=self.getBuildFlags())
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py?rev=260362&r1=260361&r2=260362&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
Wed Feb 10 00:58:13 2016
@@ -32,7 +32,7 @@ class HelloWatchLocationTestCase(TestBas
@expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not
supported
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24446:
WINDOWS XFAIL TRIAGE - Watchpoints not supported on Windows")
-@expectedFailureAll(archs=['mips', 'mipsel', 'mips64', 'mips64el']) # Most
of the MIPS boards provide only one H/W watchpoints, and S/W watchpoints are
not supported yet
+@expectedFailureAll(triple = re.compile('^mips')) # Most of the MIPS
boards provide only one H/W watchpoints, and S/W watchpoints are not supported
yet
@skipIfDarwin
def test_hello_watchlocation(self):
"""Test watching a location with '-s size' option."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py?rev=260362&r1=260361&r2=260362&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
Wed Feb 10 00:58:13 2016
@@ -74,7 +74,7 @@ class TestStepOverWatchpoint(TestBase):
# Most of the MIPS boards provide only one H/W watchpoints, and S/W
watchpoints are not supported yet
arch = self.getArchitecture()
-if arch in ['mips', 'mipsel', 'mips64', 'mips64el']:
+if re.match("^mips",arch):
self.runCmd("watchpoint delete 1")
# resolve_location=True, read=False, write=True
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
