Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-03T00:55:09+00:00 2020-01-03T00:55:09+00:00 Jonas Devlieghere jonas@devlieghere.com 2020-01-03T00:14:35+00:00 urn:sha1:d265c8bf0d1e6eed3c97dfb96f98712e5adc8bf7 2020-01-03T00:55:09+00:00 Jonas Devlieghere jonas@devlieghere.com 2020-01-03T00:13:44+00:00 urn:sha1:8580397f2e7d389940fbdd5575f26271df743aee 2019-10-29T23:56:59+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-10-29T23:26:49+00:00 urn:sha1:5cc2e0651fed7764f02421db1ba1719a10f17d25 To the best of my understanding these files or their content is nowhere referenced. 2019-03-07T17:45:53+00:00 Davide Italiano davide@freebsd.org 2019-03-07T17:45:53+00:00 urn:sha1:bd53e768d22c2c0e329bc08b2002ebd1d74ffaa6 Tests that check the output of `memory find` may trip over unreadable characters, and in Python 3 this is an error. llvm-svn: 355612 2019-02-15T07:47:06+00:00 Pavel Labath pavel@labath.sk 2019-02-15T07:47:06+00:00 urn:sha1:0af864b4b2af54a9c238df793e50b2f81f956b78 Summary: This patch finishes the python3-ification of the lldb-server test suite. It reverts the partial attempt in r352709 to encode/decode the string via utf8 before writing to the socket. This wasn't enough because the gdb-remote protocol can sometimes (but not very often) carry binary data, and the utf8 codec chokes on that. Instead I add utility functions to the "seven" module for performing "identity" transformations on the byte data. This basically drills back the hole in the python type system that the string/bytes distinction was supposed to plug. That is not ideal, but was the best solution of the alternatives I could come up with. The options I considered were: - make use of the type system to add type safety to the test suite: This required making a lot of changes to the test suite, since most of the strings would now become byte objects instead, and it was not even fully clear to me where to draw the line. One extreme solution would be to just use byte objects everywhere, as the protocol doesn't support non-ascii characters anyway. However, this appeared to be: a) weird, because most of the protocol actually deals with strings, but we would have to prefix everything with 'b' b) clunky, because the handling of the bytes objects is sufficiently different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an int in PY3). - using the latin1 codec (which gives an identity transformation for the first 256 code points of unicode) instead of the custom bytes_to_string functions. This almost could work, but it was still slightly different between python 2 and 3, because in PY2 in would return a unicode object, which would then cause problems when combined with regular strings if it contained 8-bit chars. With this in mind, I think the best solution for the time being is to just coerce everything into the string type as early as possible, and have things proceed indentically on both python versions. Once we stop supporting python3, we can revisit the idea of using bytes objects more prevasively. Reviewers: davide, zturner, serge-sans-paille Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D58177 llvm-svn: 354106 2019-01-28T18:07:28+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-01-28T18:07:28+00:00 urn:sha1:8193236b082e78292c3919cd0c1ce64d30a75172 When running the test suite on macOS with Python 3 we noticed a difference in behavior between Python 2 and Python 3 for seven.get_command_output. The output contained a newline with Python 3, but not for Python 2. This resulted in an invalid SDK path passed to the compiler. Differential revision: https://reviews.llvm.org/D57275 llvm-svn: 352397 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2018-09-01T12:15:46+00:00 Pavel Labath pavel@labath.sk 2018-09-01T12:15:46+00:00 urn:sha1:89d2245a2ac5d6690166d0752da49d011fff9a7d These happen in a couple of tests when lldb tries to pretty print a const char * variable in the inferior which points to garbage. Instead, we have the python replace the invalid sequences with the unicode replacement character. llvm-svn: 341274 2016-09-06T20:57:50+00:00 Kate Stone katherine.stone@apple.com 2016-09-06T20:57:50+00:00 urn:sha1:b9c1b51e45b845debb76d8658edabca70ca56079 *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751 2016-05-26T13:57:03+00:00 Todd Fiala todd.fiala@gmail.com 2016-05-26T13:57:03+00:00 urn:sha1:94eb010fe9a6cfe8bf1f03b8ce4cc406d56472ee This change adds the capability of building test inferiors with the -gmodules flag to enable module debug info support. Windows is excluded per @zturner. Reviewers: granata.enrico, aprantl, zturner, labath Subscribers: zturner, labath, lldb-commits Differential Revision: http://reviews.llvm.org/D19998 llvm-svn: 270848