[Lldb-commits] [PATCH] D40474: DWZ 11/12: Main functionality
labath added a comment. I am only commenting on the c++14 stuff. I think all of the things you need here are available to us already through various llvm utilities. See inline comments for details. For the "meat" of this patchset, I think clayborg is the only one who can do a proper review of that. Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h:92 // C++14: mutable std::shared_timed_mutex m_dwz_uniq_mutex; mutable std::recursive_mutex m_dwz_uniq_mutex; Is `llvm::sys::RWMutex` what you need here? Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:487 + public: +// C++14: Use heterogenous lookup. +DWZCommonFile(const lldb_private::FileSpec &filespec_ref); Have you looked at llvm::DenseSet? It already supports heterogenous lookup( `find_as(...)`). It can also be more efficient than unordered_set. Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:505 +// C++14: atomic_size_t +size_t m_use_count = 0; + Will `std::atomic` not work? https://reviews.llvm.org/D40474 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40474: DWZ 11/12: Main functionality
jankratochvil added a comment. Going to update the patch. Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h:92 // C++14: mutable std::shared_timed_mutex m_dwz_uniq_mutex; mutable std::recursive_mutex m_dwz_uniq_mutex; labath wrote: > Is `llvm::sys::RWMutex` what you need here? Yes, `llvm::sys::RWMutex` should do the trick, thanks. Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:487 + public: +// C++14: Use heterogenous lookup. +DWZCommonFile(const lldb_private::FileSpec &filespec_ref); labath wrote: > Have you looked at llvm::DenseSet? It already supports heterogenous lookup( > `find_as(...)`). It can also be more efficient than unordered_set. `llvm::DenseSet` should do the trick, thanks. Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:505 +// C++14: atomic_size_t +size_t m_use_count = 0; + labath wrote: > Will `std::atomic` not work? Yes, `std::atomic_size_t` would work but it currently has no benefit (rather a needless overhead) there without read/write locks, the atomicity makes sense if it is read-locked only. With `llvm::sys::RWMutex` now I will use the atomic type. https://reviews.llvm.org/D40474 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode
labath added a comment.
The thing to be aware of with this testing strategy is that you will probably
be the only person who will be able to run these tests and verify dwz
functionality. If you don't setup a buildbot testing this then other developers
will never even know if they have broken any dwz functionality in the future.
While end-to-end tests are great and we need them, I think it would be
worthwhile to think about other testing strategies. These can range from
checking in a couple of siple dwz files and making sure we can extract
information from them (see unittests/SymbolFile/PDB for code that does
something similar) to reimplementing/upstreaming the utilities necessary to
build dwz files ourselves (I am not sure what the `dwz` tool does, but the
`eu-strip` and `sepdebugcrcfix` tools sound like they would be fairly easy to
implement on top of existing llvm libraries).
The other thing that worries me is that your comments seem to indicate that not
all dwz tests pass after this. Could you elaborate on the "Many ERRORs are
correct" part and how you plan to rectify that?
The third thing I want to say is not really related to your patchset, but your
comments seem to indicate that not all regular dwarf tests were passing for you
to begin with. Is that true? Would you be willing to help me (probably in a
separate thread) to identify the tests that are failing and why? I'd like to
move us towards a state where the result of the tests does not depend on the
system you're running on and people don't have to resort to differential
comparisons.
Comment at: packages/Python/lldbsuite/test/test_categories.py:43
+if (os.access("/usr/lib/rpm/sepdebugcrcfix", os.X_OK)
+and distutils.spawn.find_executable("eu-strip") is not None
The way we do these sorts of things is that we explicitly add the category to
the list of skipped categories (take a look at `checkLibcxxSupport` in
dotest.py).
https://reviews.llvm.org/D40475
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r319028 - dotest: Mark more android targets as chatty
Author: labath Date: Mon Nov 27 05:47:14 2017 New Revision: 319028 URL: http://llvm.org/viewvc/llvm-project?rev=319028&view=rev Log: dotest: Mark more android targets as chatty New android ndk linker started adding more flags to the produced binaries, which causes older dynamic linkers display warnings to stderr about unsupported flags. This interferes with our stderr tests. Extend the hasChattyStderr function to catch these targets as well. Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py?rev=319028&r1=319027&r2=319028&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py Mon Nov 27 05:47:14 2017 @@ -174,6 +174,6 @@ def createPlatformContext(): def hasChattyStderr(test_case): """Some targets produce garbage on the standard error output. This utility function determines whether the tests can be strict about the expected stderr contents.""" -if match_android_device(test_case.getArchitecture(), ['aarch64'], [22]): +if match_android_device(test_case.getArchitecture(), ['aarch64'], range(22, 25+1)): return True # The dynamic linker on the device will complain about unknown DT entries return False ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r319048 - Remove custom TimePoint-formatting code
Author: labath
Date: Mon Nov 27 09:06:42 2017
New Revision: 319048
URL: http://llvm.org/viewvc/llvm-project?rev=319048&view=rev
Log:
Remove custom TimePoint-formatting code
This was a temporary thing, until llvm has proper support for formatting
time. That time has come, so we can remove the relevant code. There
should be no change in the format of the time.
Modified:
lldb/trunk/source/Commands/CommandObjectTarget.cpp
Modified: lldb/trunk/source/Commands/CommandObjectTarget.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectTarget.cpp?rev=319048&r1=319047&r2=319048&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectTarget.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectTarget.cpp Mon Nov 27 09:06:42 2017
@@ -52,6 +52,7 @@
#include "lldb/Utility/Timer.h"
#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/FormatAdapters.h"
// C Includes
// C++ Includes
@@ -135,25 +136,6 @@ static uint32_t DumpTargetList(TargetLis
return num_targets;
}
-// TODO: Remove this once llvm can pretty-print time points
-static void DumpTimePoint(llvm::sys::TimePoint<> tp, Stream &s, uint32_t
width) {
-#ifndef LLDB_DISABLE_POSIX
- char time_buf[32];
- time_t time = llvm::sys::toTimeT(tp);
- char *time_cstr = ::ctime_r(&time, time_buf);
- if (time_cstr) {
-char *newline = ::strpbrk(time_cstr, "\n\r");
-if (newline)
- *newline = '\0';
-if (width > 0)
- s.Printf("%-*s", width, time_cstr);
-else
- s.PutCString(time_cstr);
- } else if (width > 0)
-s.Printf("%-*s", width, "");
-#endif
-}
-
#pragma mark CommandObjectTargetCreate
//-
@@ -3176,7 +3158,8 @@ protected:
} break;
case 'm':
-DumpTimePoint(module->GetModificationTime(), strm, width);
+strm.Format("{0:%c}", llvm::fmt_align(module->GetModificationTime(),
+ llvm::AlignStyle::Left, width));
break;
case 'p':
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40283: lldb: Use the DWARF linkage name when importing C++ methods
clayborg added a comment. Jim will need to ok this. A few concerns follow. Most of the time when we don't get the DWARF -> AST conversion right, it can mean that we might code gen incorrect code. Is there not enough information for the GNU abi_tag in the DWARF to actually re-create these classes correctly in the AST? My first inclination would be to fix that if possible. If there is info missing from the DWARF such that we can't re-create the AST correctly, then it seems that this approach will help. Can you clarify what the GNU abi_tag stuff does? Will it change how code would be generated? If we have things in the AST that aren't correct, but have been fixed by correcting the "asm" tag, will we JIT up bad code? - https://reviews.llvm.org/D40283 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40212: DWZ 02/12: refactor: Unify+simplify DWARFCompileUnit ctor+Clear() into in-class initializers + Extract()
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Won't hold up the checkin for the cleaner while loop, but feel free to fix that
and checkin if it works.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp:248-249
-while (cu->Extract(dwarf2Data->get_debug_info_data(), &offset)) {
+for (;;) {
+ DWARFCompileUnitSP cu = DWARFCompileUnit::Extract(dwarf2Data, &offset);
+ if (cu.get() == NULL)
Might be cleaner to do:
```
DWARFCompileUnitSP cu;
while ((cu = DWARFCompileUnit::Extract(dwarf2Data, &offset))) {
```
https://reviews.llvm.org/D40212
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40466: DWZ 03/12: DWARFCompileUnit split to DWARFCompileUnitData
clayborg added inline comments. Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:216 + DWARFCompileUnitData *m_data; + Is there a reason this is a member variable that I am not seeing? Seems we could have this class inherit from DWARFCompileUnitData. I am guessing this will be needed for a future patch? https://reviews.llvm.org/D40466 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40467: DWZ 04/12: Separate Offset also into FileOffset
clayborg added a comment. It would be much easier to read this patch if there were no renames from "*offset" to "*file_offset". Can we remove these extra renames where it isn't needed? Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h:15 #include +#include Why is this added here? Doesn't seem to be needed, or it should be moved to .cpp file? https://reviews.llvm.org/D40467 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40468: DWZ 05/12: Support reading section ".gnu_debugaltlink"
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. Just move the eSectionTypeDWARFGNUDebugAltLink enumerator to the end of the enum and this is good to go. Comment at: include/lldb/lldb-enumerations.h:647 eSectionTypeDWARFAppleObjC, + eSectionTypeDWARFGNUDebugAltLink, eSectionTypeELFSymbolTable, // Elf SHT_SYMTAB section Since this enumeration is in the public API, it should be added to the end of the enum. Anyone that builds a new liblldb.so and then uses it with an binary compiled before could run into issues. But I noticed eSectionTypeDWARFDebugCuIndex was added in the middle in August, but we need to avoid these kinds of API issues, so lets add this to the end just to be safe. https://reviews.llvm.org/D40468 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40469: DWZ 06/12: Mask DW_TAG_partial_unit as DW_TAG_compile_unit for Tag()
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. Seems like it would be cleaner to leave DWARFDebugInfoEntry and DWARFDie alone and just make clients deal with accepting DW_TAG_partial_unit when and where they need to. I don't like the idea of not telling the truth. https://reviews.llvm.org/D40469 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40470: DWZ 07/12: Protect DWARFCompileUnit::m_die_array by a new mutex
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:123
size_t DWARFCompileUnit::ExtractDIEsIfNeeded(bool cu_die_only) {
- const size_t initial_die_array_size = m_data->m_die_array.size();
- if ((cu_die_only && initial_die_array_size > 0) || initial_die_array_size >
1)
-return 0; // Already parsed
+ size_t initial_die_array_size;
+ auto already_parsed = [cu_die_only, &initial_die_array_size]() -> bool {
clayborg wrote:
> I really can't tell what any of the above changed code is doing besides
> adding the mutex. Seems like you are trying to emulate a condition variable
> to halt other threads trying to get access to the DIEs. But
> m_die_array_finished isn't initialized in the constructor or inlined in the
> header file and initial_die_array_size isn't initialized so I can't really
> tell what this is supposed to actually do.
This isn't initialized and it is captured and used in already_parsed below?
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:123-137
+ size_t initial_die_array_size;
+ auto already_parsed = [cu_die_only, &initial_die_array_size]() -> bool {
+return (cu_die_only && initial_die_array_size > 0)
+|| initial_die_array_size > 1;
+ };
+ if (already_parsed() && m_data->m_die_array_finished)
+return 0;
I really can't tell what any of the above changed code is doing besides adding
the mutex. Seems like you are trying to emulate a condition variable to halt
other threads trying to get access to the DIEs. But m_die_array_finished isn't
initialized in the constructor or inlined in the header file and
initial_die_array_size isn't initialized so I can't really tell what this is
supposed to actually do.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:128
+ };
+ if (already_parsed() && m_data->m_die_array_finished)
+return 0;
initial_die_array_size is used uninitialized when calling already_parsed()
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:131
+ std::lock_guard guard(m_data->m_extractdies_mutex);
+ if (already_parsed()) {
+lldbassert(m_data->m_die_array_finished);
initial_die_array_size is used uninitialized when calling already_parsed()
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:74
+ std::mutex m_extractdies_mutex;
+ bool m_die_array_finished;
+
This isn't initialized anywhere.
https://reviews.llvm.org/D40470
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40283: lldb: Use the DWARF linkage name when importing C++ methods
nelhage added a comment.
In https://reviews.llvm.org/D40283#936088, @clayborg wrote:
> Jim will need to ok this. A few concerns follow. Most of the time when we
> don't get the DWARF -> AST conversion right, it can mean that we might code
> gen incorrect code. Is there not enough information for the GNU abi_tag in
> the DWARF to actually re-create these classes correctly in the AST?
Correct, as far as I can tell. Looking at a symbol definition from the test
program on the issue via `llvm-dwarfdump`, I see
0x0076: DW_TAG_subprogram
DW_AT_linkage_name("_ZN1A16helloWorld_cxx11B5cxx11Ev")
DW_AT_name("helloWorld_cxx11")
DW_AT_decl_file ("/tmp/test_abi_tag.cc")
DW_AT_decl_line (5)
DW_AT_declaration (true)
DW_AT_external(true)
DW_AT_accessibility (DW_ACCESS_public)
0x0082: DW_TAG_formal_parameter
DW_AT_type (cu + 0x009b "A*")
DW_AT_artificial(true)
0x0087: NULL
The function of the `abi_tag` annotation is to append the `B5cxx11` to the
mangled name; I can't find any other indication in the DWARF of the ABI tag.
You can read more about `abi_tag` here:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
Or an explanation of why it exists and how it is used here:
https://davmac.wordpress.com/2015/07/19/tale-of-two-abis/
The effect of this patch on the code generated by `expression` is to change the
names we emit into the LLVM IR; Previously, we would emit a call to
`_ZN1A16helloWorld_cxx11Ev`, which would then fail when resolving symbols. Now
we (correctly) emit a call to `_ZN1A16helloWorld_cxx11B5cxx11Ev`.
The test case I added in this patch also demonstrates that GCC and clang both
support arbitrarily overriding a symbol's mangled name in the source using
`asm("new_name")`. I can't recall having ever encountered a use of that in the
wild, so I don't care strongly about supporting it, but if we want to I think
this general approach is almost certainly the only approach that would do so.
https://reviews.llvm.org/D40283
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40471: DWZ 08/12: DWARFCompileUnit::ExtractDIEsIfNeeded can now expand AllDiesButCuDieOnlyForPartialUnits
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. See inline comments. Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2050-2052 +if (dwarf_cu->ExtractDIEsIfNeeded(DWARFCompileUnit:: +ExtractDIEsIfNeededKind::AllDiesButCuDieOnlyForPartialUnits) > 1) clear_cu_dies[cu_idx] = true; All of these changes can be avoided by just appropriately checking for partial units and skipping them in this index function. Do you plan on using this functionality in any other place? I would rather you just fix this function to filter out the partial units. https://reviews.llvm.org/D40471 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40472: DWZ 09/12: Protect DWARFDebugInfo::m_compile_units by a new mutex
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
DWARFDebugInfo::ParseCompileUnitHeadersIfNeeded() seems broken, see inlined
comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp:114-119
+{
+ // C++14: std::lock_guard
+ // guard(m_dwz_uniq_mutex);
+ std::lock_guard guard(m_dwz_uniq_mutex);
+ m_compile_units.push_back(cu_sp);
}
So if some code calls DWARFDebugInfo::ParseCompileUnitHeadersIfNeeded() after
this loop has added 1 compile unit they will return and be able to proceed?
This doesn't make sense.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h:80
+ // C++14: mutable std::shared_timed_mutex m_dwz_uniq_mutex;
+ mutable std::recursive_mutex m_dwz_uniq_mutex;
+
Why is this named m_dwz_uniq_mutex? Seems to be protected m_compile_units.
Should this be named "m_compile_units_mutex"?
https://reviews.llvm.org/D40472
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40473: DWZ 10/12: Adjust existing code for the DWZ support.
clayborg requested changes to this revision. clayborg added inline comments. This revision now requires changes to proceed. Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp:199-202 + if (die_ref.cu_offset == DW_INVALID_OFFSET + // FIXME: Workaround default cu_offset = 0 in DIERef ctor. + // Why does GetCompileUnit exist at all? + || (die_ref.cu_offset == 0 /* && m_dwarf2Data->GetDWZSymbolFile() */ )) Just fix the DIERef constructor to not use 0 for the cu_offset? Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:388-390 + // DIERef(DWARFFormValue)->DWARFFormValue::Reference() may need + // FileOffsetToUniqOffset. + dwarf2Data->PreloadSymbols(); This seems like the wrong place to do this call. We are asking all DWARF to index itself from DWARFDebugInfoEntry::GetDIENamesAndRanges()? Doesn't seem like the right place. https://reviews.llvm.org/D40473 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40283: lldb: Use the DWARF linkage name when importing C++ methods
clayborg added a comment. ok, sounds like the abi_tag stuff is meant to just affect the mangled named with no code gen implications. Jim should ok this, but I am ok if he is. https://reviews.llvm.org/D40283 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40517: Mark UUID::GetByteSize() const
sas created this revision.
This method doesn't modify anything in the object it's called on so we
can mark it const to make it usable in a const context.
https://reviews.llvm.org/D40517
Files:
include/lldb/Utility/UUID.h
source/Utility/UUID.cpp
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -109,7 +109,7 @@
return false;
}
-size_t UUID::GetByteSize() { return m_num_uuid_bytes; }
+size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
Index: include/lldb/Utility/UUID.h
===
--- include/lldb/Utility/UUID.h
+++ include/lldb/Utility/UUID.h
@@ -46,7 +46,7 @@
const void *GetBytes() const;
- size_t GetByteSize();
+ size_t GetByteSize() const;
bool IsValid() const;
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -109,7 +109,7 @@
return false;
}
-size_t UUID::GetByteSize() { return m_num_uuid_bytes; }
+size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
Index: include/lldb/Utility/UUID.h
===
--- include/lldb/Utility/UUID.h
+++ include/lldb/Utility/UUID.h
@@ -46,7 +46,7 @@
const void *GetBytes() const;
- size_t GetByteSize();
+ size_t GetByteSize() const;
bool IsValid() const;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r319095 - Mark UUID::GetByteSize() const
Author: sas
Date: Mon Nov 27 13:16:37 2017
New Revision: 319095
URL: http://llvm.org/viewvc/llvm-project?rev=319095&view=rev
Log:
Mark UUID::GetByteSize() const
Summary:
This method doesn't modify anything in the object it's called on so we
can mark it const to make it usable in a const context.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40517
Modified:
lldb/trunk/include/lldb/Utility/UUID.h
lldb/trunk/source/Utility/UUID.cpp
Modified: lldb/trunk/include/lldb/Utility/UUID.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/UUID.h?rev=319095&r1=319094&r2=319095&view=diff
==
--- lldb/trunk/include/lldb/Utility/UUID.h (original)
+++ lldb/trunk/include/lldb/Utility/UUID.h Mon Nov 27 13:16:37 2017
@@ -46,7 +46,7 @@ public:
const void *GetBytes() const;
- size_t GetByteSize();
+ size_t GetByteSize() const;
bool IsValid() const;
Modified: lldb/trunk/source/Utility/UUID.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/UUID.cpp?rev=319095&r1=319094&r2=319095&view=diff
==
--- lldb/trunk/source/Utility/UUID.cpp (original)
+++ lldb/trunk/source/Utility/UUID.cpp Mon Nov 27 13:16:37 2017
@@ -109,7 +109,7 @@ bool UUID::SetBytes(const void *uuid_byt
return false;
}
-size_t UUID::GetByteSize() { return m_num_uuid_bytes; }
+size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40517: Mark UUID::GetByteSize() const
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319095: Mark UUID::GetByteSize() const (authored by sas).
Repository:
rL LLVM
https://reviews.llvm.org/D40517
Files:
lldb/trunk/include/lldb/Utility/UUID.h
lldb/trunk/source/Utility/UUID.cpp
Index: lldb/trunk/include/lldb/Utility/UUID.h
===
--- lldb/trunk/include/lldb/Utility/UUID.h
+++ lldb/trunk/include/lldb/Utility/UUID.h
@@ -46,7 +46,7 @@
const void *GetBytes() const;
- size_t GetByteSize();
+ size_t GetByteSize() const;
bool IsValid() const;
Index: lldb/trunk/source/Utility/UUID.cpp
===
--- lldb/trunk/source/Utility/UUID.cpp
+++ lldb/trunk/source/Utility/UUID.cpp
@@ -109,7 +109,7 @@
return false;
}
-size_t UUID::GetByteSize() { return m_num_uuid_bytes; }
+size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
Index: lldb/trunk/include/lldb/Utility/UUID.h
===
--- lldb/trunk/include/lldb/Utility/UUID.h
+++ lldb/trunk/include/lldb/Utility/UUID.h
@@ -46,7 +46,7 @@
const void *GetBytes() const;
- size_t GetByteSize();
+ size_t GetByteSize() const;
bool IsValid() const;
Index: lldb/trunk/source/Utility/UUID.cpp
===
--- lldb/trunk/source/Utility/UUID.cpp
+++ lldb/trunk/source/Utility/UUID.cpp
@@ -109,7 +109,7 @@
return false;
}
-size_t UUID::GetByteSize() { return m_num_uuid_bytes; }
+size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40519: Remove some duplicated code in UUID.cpp
sas created this revision.
Formatting needs to be done only once. Ran check-lldb and nothing changes.
https://reviews.llvm.org/D40519
Files:
source/Utility/UUID.cpp
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -74,14 +74,8 @@
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ auto str = GetAsString();
+ s->Printf("%s", str.c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -74,14 +74,8 @@
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ auto str = GetAsString();
+ s->Printf("%s", str.c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40283: lldb: Use the DWARF linkage name when importing C++ methods
jingham added a comment. This patch is actually pretty broad, since it will make all C++ declarations coming from DWARF have overridden names so far as clang is concerned. So we are relying on the fact that as far as clang is concerned a method with an asm assigned name is equivalent to method whose name mangles to the same thing. From what I can tell scanning through the clang sources, this attribute just overrides whatever mangling clang was intending to do for this decl. There shouldn't be any case where we have an incorrect mangled name in the DWARF so at first glance that should be okay. But since this affects all C++ method names that we pass to clang, I'd feel better if we could get confirmation from a clang expert that this change has no other side-effects. https://reviews.llvm.org/D40283 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40519: Remove some duplicated code in UUID.cpp
davide accepted this revision. davide added a comment. LGTM https://reviews.llvm.org/D40519 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40519: Remove some duplicated code in UUID.cpp
zturner added inline comments.
Comment at: source/Utility/UUID.cpp:77-78
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ auto str = GetAsString();
+ s->Printf("%s", str.c_str());
}
Minor nit, but when you have a string and only want to print that string and
nothing else, I would usually prefer not using printf syntax and instead just
using `PutCString`.
https://reviews.llvm.org/D40519
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40519: Remove some duplicated code in UUID.cpp
sas updated this revision to Diff 124499.
sas added a comment.
Address @zturner's comment and remove a useless temporary variable.
https://reviews.llvm.org/D40519
Files:
source/Utility/UUID.cpp
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -74,14 +74,7 @@
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ s->PutCString(GetAsString().c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -74,14 +74,7 @@
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ s->PutCString(GetAsString().c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r319132 - Remove some duplicated code in UUID.cpp
Author: sas
Date: Mon Nov 27 17:26:07 2017
New Revision: 319132
URL: http://llvm.org/viewvc/llvm-project?rev=319132&view=rev
Log:
Remove some duplicated code in UUID.cpp
Summary: Formatting needs to be done only once. Ran check-lldb and nothing
changes.
Reviewers: clayborg, davide
Reviewed By: clayborg, davide
Subscribers: zturner, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D40519
Modified:
lldb/trunk/source/Utility/UUID.cpp
Modified: lldb/trunk/source/Utility/UUID.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/UUID.cpp?rev=319132&r1=319131&r2=319132&view=diff
==
--- lldb/trunk/source/Utility/UUID.cpp (original)
+++ lldb/trunk/source/Utility/UUID.cpp Mon Nov 27 17:26:07 2017
@@ -74,14 +74,7 @@ std::string UUID::GetAsString(const char
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ s->PutCString(GetAsString().c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40519: Remove some duplicated code in UUID.cpp
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319132: Remove some duplicated code in UUID.cpp (authored by
sas).
Repository:
rL LLVM
https://reviews.llvm.org/D40519
Files:
lldb/trunk/source/Utility/UUID.cpp
Index: lldb/trunk/source/Utility/UUID.cpp
===
--- lldb/trunk/source/Utility/UUID.cpp
+++ lldb/trunk/source/Utility/UUID.cpp
@@ -74,14 +74,7 @@
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ s->PutCString(GetAsString().c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
Index: lldb/trunk/source/Utility/UUID.cpp
===
--- lldb/trunk/source/Utility/UUID.cpp
+++ lldb/trunk/source/Utility/UUID.cpp
@@ -74,14 +74,7 @@
}
void UUID::Dump(Stream *s) const {
- const uint8_t *u = (const uint8_t *)GetBytes();
- s->Printf("%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X%"
-"2.2X%2.2X%2.2X%2.2X",
-u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9], u[10],
-u[11], u[12], u[13], u[14], u[15]);
- if (m_num_uuid_bytes == 20) {
-s->Printf("-%2.2X%2.2X%2.2X%2.2X", u[16], u[17], u[18], u[19]);
- }
+ s->PutCString(GetAsString().c_str());
}
bool UUID::SetBytes(const void *uuid_bytes, uint32_t num_uuid_bytes) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40536: Simplify UUID constructors
sas created this revision.
This remove a small amount of duplicated code.
https://reviews.llvm.org/D40536
Files:
source/Utility/UUID.cpp
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -21,11 +21,10 @@
namespace lldb_private {
-UUID::UUID() : m_num_uuid_bytes(16) { ::memset(m_uuid, 0, sizeof(m_uuid)); }
+UUID::UUID() { Clear(); }
UUID::UUID(const UUID &rhs) {
- m_num_uuid_bytes = rhs.m_num_uuid_bytes;
- ::memcpy(m_uuid, rhs.m_uuid, sizeof(m_uuid));
+ SetBytes(rhs.m_uuid, rhs.m_num_uuid_bytes);
}
UUID::UUID(const void *uuid_bytes, uint32_t num_uuid_bytes) {
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -21,11 +21,10 @@
namespace lldb_private {
-UUID::UUID() : m_num_uuid_bytes(16) { ::memset(m_uuid, 0, sizeof(m_uuid)); }
+UUID::UUID() { Clear(); }
UUID::UUID(const UUID &rhs) {
- m_num_uuid_bytes = rhs.m_num_uuid_bytes;
- ::memcpy(m_uuid, rhs.m_uuid, sizeof(m_uuid));
+ SetBytes(rhs.m_uuid, rhs.m_num_uuid_bytes);
}
UUID::UUID(const void *uuid_bytes, uint32_t num_uuid_bytes) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()
sas created this revision.
This change also prevents looking further than the size of the current
UUID.
https://reviews.llvm.org/D40537
Files:
source/Utility/UUID.cpp
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -15,9 +15,12 @@
#include "llvm/ADT/StringRef.h"
// C Includes
+// C++ Includes
#include
#include
#include
+#include
+#include
namespace lldb_private {
@@ -104,10 +107,8 @@
size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
- return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
- m_uuid[5] || m_uuid[6] || m_uuid[7] || m_uuid[8] || m_uuid[9] ||
- m_uuid[10] || m_uuid[11] || m_uuid[12] || m_uuid[13] || m_uuid[14] ||
- m_uuid[15] || m_uuid[16] || m_uuid[17] || m_uuid[18] || m_uuid[19];
+ return std::any_of(std::begin(m_uuid), std::begin(m_uuid) + m_num_uuid_bytes,
+ [](uint32_t val) { return val != 0; });
}
static inline int xdigit_to_int(char ch) {
Index: source/Utility/UUID.cpp
===
--- source/Utility/UUID.cpp
+++ source/Utility/UUID.cpp
@@ -15,9 +15,12 @@
#include "llvm/ADT/StringRef.h"
// C Includes
+// C++ Includes
#include
#include
#include
+#include
+#include
namespace lldb_private {
@@ -104,10 +107,8 @@
size_t UUID::GetByteSize() const { return m_num_uuid_bytes; }
bool UUID::IsValid() const {
- return m_uuid[0] || m_uuid[1] || m_uuid[2] || m_uuid[3] || m_uuid[4] ||
- m_uuid[5] || m_uuid[6] || m_uuid[7] || m_uuid[8] || m_uuid[9] ||
- m_uuid[10] || m_uuid[11] || m_uuid[12] || m_uuid[13] || m_uuid[14] ||
- m_uuid[15] || m_uuid[16] || m_uuid[17] || m_uuid[18] || m_uuid[19];
+ return std::any_of(std::begin(m_uuid), std::begin(m_uuid) + m_num_uuid_bytes,
+ [](uint32_t val) { return val != 0; });
}
static inline int xdigit_to_int(char ch) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40539: Allow using the object file name for debug symbol resolution
sas created this revision.
Herald added subscribers: JDevlieghere, emaste.
In ObjectFileELF we try to read the `.gnu_debuglink` section of the ELF
file to determine the name of the debug symbols file. If this section
does not exist, we stop the search. Instead, what we should do is locate
a file with the same name as the ELF binary, which is the default
behavior when there isn't any `.gnu_debuglink` section present.
Ran check-lldb to make sure this doesn't break anything.
https://reviews.llvm.org/D40539
Files:
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1000,7 +1000,11 @@
if (!m_gnu_debuglink_file.empty()) {
FileSpec file_spec(m_gnu_debuglink_file, false);
file_spec_list.Append(file_spec);
+ } else {
+FileSpec file_spec(GetFileSpec().GetFilename().AsCString(), false);
+file_spec_list.Append(file_spec);
}
+
return file_spec_list;
}
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1000,7 +1000,11 @@
if (!m_gnu_debuglink_file.empty()) {
FileSpec file_spec(m_gnu_debuglink_file, false);
file_spec_list.Append(file_spec);
+ } else {
+FileSpec file_spec(GetFileSpec().GetFilename().AsCString(), false);
+file_spec_list.Append(file_spec);
}
+
return file_spec_list;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()
zturner added a comment. You could use llvm's range adapters to make this slightly better. auto Bytes = makeArrayRef(m_uuid, m_num_uuid_bytes); return llvm::find(Bytes, 0) != Bytes.end(); Another option would just be `return *this != UUID(m_num_uuid_bytes);` https://reviews.llvm.org/D40537 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for the week of 11/12/2017 - 11/18/2017
Hello everyone, Below are some buildbot numbers for the week of 11/12/2017 - 11/18/2017. Please see the same data in attached csv files: The longest time each builder was red during the week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed builds and average build time for successful builds per active builder; Average waiting time for a revision to get build result per active builder (response time). Thanks Galina The longest time each builder was red during the week: buildername | was_red ---+-- clang-x86-windows-msvc2015| 124:07:17 clang-with-thin-lto-windows | 123:19:05 llvm-clang-x86_64-expensive-checks-win| 86:15:46 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-cxx1z| 55:04:41 clang-x86_64-linux-selfhost-modules-2 | 40:41:05 reverse-iteration | 38:32:59 clang-cuda-build | 38:28:37 clang-x86_64-linux-selfhost-modules | 36:51:36 clang-with-lto-ubuntu | 30:18:33 clang-tools-sphinx-docs | 28:59:16 clang-x86_64-debian-fast | 28:47:47 clang-with-thin-lto-ubuntu| 28:47:14 clang-cmake-aarch64-full | 28:21:42 clang-ppc64le-linux-lnt | 27:52:12 clang-ppc64le-linux | 27:37:31 clang-x64-ninja-win7 | 26:40:06 lldb-x86_64-darwin-13.4 | 23:25:45 sanitizer-x86_64-linux-bootstrap-msan | 22:24:00 clang-ppc64be-linux-lnt | 21:09:10 clang-ppc64be-linux-multistage| 19:12:23 clang-ppc64be-linux | 16:38:30 clang-s390x-linux-multistage | 16:28:55 clang-cmake-armv7-a15-selfhost-neon | 15:20:45 clang-ppc64le-linux-multistage| 14:33:36 clang-s390x-linux-lnt | 14:09:06 clang-s390x-linux | 14:08:00 sanitizer-x86_64-linux-bootstrap-ubsan| 13:58:42 sanitizer-x86_64-linux-bootstrap | 13:58:04 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 12:24:47 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 11:46:46 clang-cmake-thumbv7-a15-full-sh | 11:42:50 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 10:38:28 clang-lld-x86_64-2stage | 10:20:53 perf-x86_64-penryn-O3-polly-unprofitable | 10:07:28 perf-x86_64-penryn-O3-polly-parallel-fast | 09:48:10 sanitizer-x86_64-linux-fast | 08:37:43 lld-x86_64-freebsd| 07:20:40 lld-x86_64-darwin13 | 07:20:27 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 07:14:52 clang-x86_64-linux-abi-test | 07:02:43 lld-x86_64-win7 | 06:23:57 clang-atom-d525-fedora-rel| 06:19:25 clang-cmake-armv7-a15-selfhost| 06:06:35 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 05:38:34 libcxx-libcxxabi-libunwind-x86_64-linux-debian| 05:21:43 clang-hexagon-elf | 04:16:58 ubuntu-gcc7.1-werror | 04:05:18 sanitizer-ppc64be-linux | 04:00:09 lldb-windows7-android | 03:59:10 clang-cmake-aarch64-lld | 03:57:35 polly-amd64-linux | 03:54:57 clang-cmake-x86_64-sde-avx512-linux | 03:44:42 aosp-O3-polly-before-vectorizer-unprofitable | 03:40:51 clang-cmake-aarch64-global-isel | 03:32:11 lldb-amd64-ninja-netbsd8 | 03:13:13 clang-cmake-x86_64-avx2-linux | 03:10:24 clang-cmake-x86_64-avx2-linux-perf| 03:09:04 libcxx-libcxxabi-libunwind-aarch64-linux | 02:57:21 clang-cmake-aarch64-quick | 02:51:15 lldb-x86_64-ubuntu-14.04-buildserver | 02:47:47 lldb-x86_64-ubuntu-14.04-cmake| 02:41:48 sanitizer-x86_64-linux-android| 02:37:56 sanitizer-x86_64-linux| 02:33:28 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 02:24:52 clang-cmak
[Lldb-commits] Buildbot numbers for the week of 11/19/2017 - 11/25/2017
Hello everyone, Below are some buildbot numbers for the last week of 11/19/2017 - 11/25/2017. Please see the same data in attached csv files: The longest time each builder was red during the week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed builds and average build time for successful builds per active builder; Average waiting time for a revision to get build result per active builder (response time). Thanks Galina The longest time each builder was red during the week: buildername | was_red ---+- polly-amd64-linux | 53:09:48 polly-arm-linux | 52:10:52 openmp-clang-ppc64le-linux-debian | 35:38:57 lldb-windows7-android | 24:28:46 llvm-mips-linux | 20:40:17 openmp-clang-x86_64-linux-debian | 15:06:46 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17| 15:03:06 libcxx-libcxxabi-libunwind-arm-linux | 15:02:57 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 15:02:52 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 15:02:48 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 15:02:48 libcxx-libcxxabi-libunwind-aarch64-linux | 15:02:45 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 15:02:42 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 15:02:22 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan| 15:02:09 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 15:01:09 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a| 15:01:05 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 15:01:03 clang-with-thin-lto-windows | 12:32:14 clang-lld-x86_64-2stage | 10:29:08 clang-x64-ninja-win7 | 08:39:49 sanitizer-x86_64-linux-bootstrap-msan | 08:36:36 clang-s390x-linux-multistage | 08:26:17 clang-cmake-aarch64-full | 08:23:29 sanitizer-x86_64-linux-bootstrap | 07:59:01 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 07:35:28 sanitizer-x86_64-linux-fast | 07:33:16 sanitizer-x86_64-linux-bootstrap-ubsan| 07:16:23 clang-cmake-x86_64-avx2-linux | 06:59:15 clang-ppc64be-linux-multistage| 06:57:37 clang-with-thin-lto-ubuntu| 06:57:03 llvm-clang-x86_64-expensive-checks-win| 06:47:18 clang-ppc64le-linux-lnt | 06:45:11 clang-with-lto-ubuntu | 06:39:57 clang-ppc64le-linux-multistage| 06:31:54 clang-x86-windows-msvc2015| 06:30:13 reverse-iteration | 06:18:22 clang-x86_64-linux-selfhost-modules | 06:00:39 sanitizer-x86_64-linux-android| 05:59:44 lld-x86_64-freebsd| 05:59:17 clang-cmake-x86_64-sde-avx512-linux | 05:56:49 clang-ppc64le-linux | 05:49:16 clang-s390x-linux-lnt | 05:48:53 clang-x86_64-linux-selfhost-modules-2 | 05:48:30 clang-s390x-linux | 05:46:30 clang-ppc64be-linux | 05:28:02 clang-ppc64be-linux-lnt | 05:17:19 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 05:16:14 clang-atom-d525-fedora-rel| 05:14:34 clang-cmake-aarch64-lld | 04:52:23 clang-cmake-armv7-a15-selfhost-neon | 04:23:39 clang-hexagon-elf | 04:19:57 clang-cmake-aarch64-global-isel | 04:18:31 clang-cmake-aarch64-quick | 04:17:24 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 04:16:18 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 04:16:06 clang-cmake-thumbv7-a15 | 04:12:57 clang-cmake-armv7-a15 | 04:06:56 clang-cmake-armv7-a15-selfhost| 04:03:10 clang-cmake-thumbv7-a15-full-sh | 03:47:29 clang-cmake-armv7-a15-full| 03:26:09 sanitizer-ppc64be-linux | 02:11:49 lldb-x86_64-darwin-13.4 | 01:50:21 lldb-x86_64-ubuntu-14.04-cmake| 01:31:48 sanitizer
[Lldb-commits] [PATCH] D40536: Simplify UUID constructors
davide accepted this revision. davide added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D40536 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()
davide added a comment. Yes, what Zachary said. Thanks for the cleanup. There's a decent amount of code in lldb that can be written in a very compact way but it's manually unrolled. I think in this case the code produced should be equivalent (and if not, I'd be curious to see the codegen). More generally, whenever a function is not in a hot loop, we might consider preferring readability over performances anyway. https://reviews.llvm.org/D40537 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D40539: Allow using the object file name for debug symbol resolution
davide added subscribers: vsk, aprantl, davide. davide added a comment. I thought about this, and it's the only patch from your patchset that I don't feel really confident about. I'm afraid it's a little risky to add more code to the objectfile reader without having proper unittesting. In particular, we might want to either check in an object file (not so ideal) or use `llvm-mc` to produce a file with the correct section. More generally, when we want to test debug info either we want to piggyback on mc or yaml2obj. If none of them suffices, we should think about having a tool that takes a textual representation of some sort (YAML seems a good start) and produces a core dump to be passed to LLDB. @sas what do you think? cc:ing @vsk / @aprantl for thoughts. https://reviews.llvm.org/D40539 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()
As an aside, I don't really like this class. For example, You can currently assign a UUID[16] to a UUID[20]. That doesn't make a lot of sense to me. As a future cleanup, I think this class should probably be a template such as UUID, and then internally it can store a std::array. And we can static_assert that N is of a known size if we desire. On Mon, Nov 27, 2017 at 9:38 PM Davide Italiano via Phabricator < revi...@reviews.llvm.org> wrote: > davide added a comment. > > Yes, what Zachary said. Thanks for the cleanup. There's a decent amount of > code in lldb that can be written in a very compact way but it's manually > unrolled. I think in this case the code produced should be equivalent (and > if not, I'd be curious to see the codegen). > More generally, whenever a function is not in a hot loop, we might > consider preferring readability over performances anyway. > > > https://reviews.llvm.org/D40537 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D40539: Allow using the object file name for debug symbol resolution
yaml2core would be an excellent idea for a tool. On Mon, Nov 27, 2017 at 9:48 PM Davide Italiano via Phabricator via lldb-commits wrote: > davide added subscribers: vsk, aprantl, davide. > davide added a comment. > > I thought about this, and it's the only patch from your patchset that I > don't feel really confident about. > I'm afraid it's a little risky to add more code to the objectfile reader > without having proper unittesting. > In particular, we might want to either check in an object file (not so > ideal) or use `llvm-mc` to produce a file with the correct section. > More generally, when we want to test debug info either we want to > piggyback on mc or yaml2obj. > If none of them suffices, we should think about having a tool that takes a > textual representation of some sort (YAML seems a good start) and produces > a core dump to be passed to LLDB. > @sas what do you think? > cc:ing @vsk / @aprantl for thoughts. > > > https://reviews.llvm.org/D40539 > > > > ___ > 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
