<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/lldb/source/Plugins/Process, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2020-03-03T13:31:05+00:00</updated>
<entry>
<title>Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)</title>
<updated>2020-03-03T13:31:05+00:00</updated>
<author>
<name>Hans Wennborg</name>
<email>hans@chromium.org</email>
</author>
<published>2020-03-03T08:45:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=5f9211bc46fa1a8d1db3a2bc27c2b115cd617795'/>
<id>urn:sha1:5f9211bc46fa1a8d1db3a2bc27c2b115cd617795</id>
<content type='text'>
and follow-ups:
a2ca1c2d "build: disable zlib by default on Windows"
2181bf40 "[CMake] Link against ZLIB::ZLIB"
1079c68a "Attempt to fix ZLIB CMake logic on Windows"

This changed the output of llvm-config --system-libs, and more
importantly it broke stand-alone builds. Instead of piling on more fix
attempts, let's revert this to reduce the risk of more breakages.

(cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
</content>
</entry>
<entry>
<title>When reading Aux file in chunks, read consecutive byte ranges</title>
<updated>2020-01-10T00:05:38+00:00</updated>
<author>
<name>Jason Molenda</name>
<email>jmolenda@apple.com</email>
</author>
<published>2020-01-10T00:05:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=02113918ed6b5e514afd7d1e007131d36ac13f1d'/>
<id>urn:sha1:02113918ed6b5e514afd7d1e007131d36ac13f1d</id>
<content type='text'>
qemu has a very small maximum packet size (4096) and it actually
only uses half of that buffer for some implementation reason,
so when lldb asks for the register target definitions, the x86_64
definition is larger than 4096/2 and we need to fetch it in two parts.

This patch and test is fixing a bug in
GDBRemoteCommunicationClient::ReadExtFeature when reading a target
file in multiple parts.  lldb was assuming that it would always
get back the maximum packet size response (4096) instead of
using the actual size received and asking for the next group of
bytes.

We now have two tests in gdb_remote_client for unique features
of qemu - TestNestedRegDefinitions.py would test the ability
of lldb to follow multiple levels of xml includes; I opted to
create a separate TestRegDefinitionInParts.py test to test this
wrinkle in qemu's gdb remote serial protocol stub implementation.
Instead of combining both tests into a single test file.

&lt;rdar://problem/49537922&gt;
</content>
</entry>
<entry>
<title>[lldb][NFC] Use static_cast instead of reinterpret_cast where possible</title>
<updated>2020-01-07T12:03:56+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2020-01-07T11:13:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=65fdb34219f33b2871a532a38814ac4ebea10abc'/>
<id>urn:sha1:65fdb34219f33b2871a532a38814ac4ebea10abc</id>
<content type='text'>
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.

Reviewers: shafik, JDevlieghere, labath

Reviewed By: labath

Subscribers: arphaman, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72161
</content>
</entry>
<entry>
<title>[lldb] [Process/NetBSD] Remove unused orig_*ax use</title>
<updated>2020-01-06T16:10:55+00:00</updated>
<author>
<name>Michał Górny</name>
<email>mgorny@gentoo.org</email>
</author>
<published>2020-01-04T04:34:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=bc763c42bbcf830ad4e543ddc8c39cd146790176'/>
<id>urn:sha1:bc763c42bbcf830ad4e543ddc8c39cd146790176</id>
<content type='text'>
orig_*ax logic is Linux-specific, and was never used on NetBSD.
In fact, its support seems to be a dead code entirely.

Differential Revision: https://reviews.llvm.org/D72195
</content>
</entry>
<entry>
<title>build: reduce CMake handling for zlib</title>
<updated>2020-01-02T19:19:12+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2020-01-01T23:01:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=abb00753069554c538f3d850897373d093389945'/>
<id>urn:sha1:abb00753069554c538f3d850897373d093389945</id>
<content type='text'>
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28,
e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad.  The problem with the windows
bot is a need for clearing the cache.
</content>
</entry>
<entry>
<title>Revert "build: reduce CMake handling for zlib"</title>
<updated>2020-01-02T16:02:10+00:00</updated>
<author>
<name>James Henderson</name>
<email>jh7370@my.bristol.ac.uk</email>
</author>
<published>2020-01-02T15:35:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=e406cca5f9a6477c9861717f81c156aa83feeaca'/>
<id>urn:sha1:e406cca5f9a6477c9861717f81c156aa83feeaca</id>
<content type='text'>
This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28.

This commit broke the clang-x64-windows-msvc build bot and a follow-up
commit did not fix it. Reverting to fix the bot.
</content>
</entry>
<entry>
<title>build: reduce CMake handling for zlib</title>
<updated>2020-01-02T00:36:59+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2020-01-01T23:01:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=68a235d07f9e7049c7eb0c8091f37e385327ac28'/>
<id>urn:sha1:68a235d07f9e7049c7eb0c8091f37e385327ac28</id>
<content type='text'>
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
</content>
</entry>
<entry>
<title>[lldb][NFC] Move lock scope where it should begin</title>
<updated>2019-12-26T15:49:35+00:00</updated>
<author>
<name>Tatyana Krasnukha</name>
<email>tatyana@synopsys.com</email>
</author>
<published>2019-12-26T12:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=b0469eede2857f8c15bbec3db7605f699324befb'/>
<id>urn:sha1:b0469eede2857f8c15bbec3db7605f699324befb</id>
<content type='text'>
</content>
</entry>
<entry>
<title>[lldb] Adapt for NetBSD-9.99.30 ptrace(2) API changes</title>
<updated>2019-12-24T19:36:23+00:00</updated>
<author>
<name>Kamil Rytarowski</name>
<email>n54@gmx.com</email>
</author>
<published>2019-12-24T19:36:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=ab8a7a29bf15c6eb1d4393516cde1688dbe7dc45'/>
<id>urn:sha1:ab8a7a29bf15c6eb1d4393516cde1688dbe7dc45</id>
<content type='text'>
Switch from PT_LWPINFO to PT_LWPSTATUS/PT_LWPNEXT.

Keep compat support for &lt; 9.99.30.

No functional change intended.
</content>
</entry>
<entry>
<title>[lldb] Fix ARM32 inferior calls</title>
<updated>2019-12-21T10:12:17+00:00</updated>
<author>
<name>Jan Kratochvil</name>
<email>jan.kratochvil@redhat.com</email>
</author>
<published>2019-12-21T10:12:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=df6879ec0227a8a5e5697e505201d0f4444f03a4'/>
<id>urn:sha1:df6879ec0227a8a5e5697e505201d0f4444f03a4</id>
<content type='text'>
  echo -e '#include &lt;unistd.h&gt;\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'

Actual:

  error: Expression can't be run, because there is no JIT compiled function

Expected:

  &lt;nothing, sync() has been executed&gt;

This patch has been checked by:
  D71707: clang-tidy: new bugprone-pointer-cast-widening
  https://reviews.llvm.org/D71707

Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:

  echo -e '#include &lt;stdio.h&gt;\n#include &lt;stdint.h&gt;\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
  &lt;stdin&gt;: In function ‘main’:
  &lt;stdin&gt;:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000

With debug output:
Actual:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
  Code can be run in the target.
  Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
  Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
  Sections:
  [0xb6f84000+0x3c]-&gt;0xb6ff9020 (alignment 4, section ID 0, name .text)
  ...
  HandleCommand, command did not succeed
  error: Expression can't be run, because there is no JIT compiled function

Expected:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
  IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
  Code can be run in the target.
  Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
  Function's code range is [0xb6ff9020+0x40]
  ...
  Function data has contents:
  0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
  ...
  Function disassembly:
  0xb6ff9020: 0xe92d4c10   push   {r4, r10, r11, lr}

Differential revision: https://reviews.llvm.org/D71498
</content>
</entry>
</feed>
