profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/kastiglione/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Dave Lee kastiglione Apple Menlo Park, CA

jspahrsummers/libextobjc 4522

A Cocoa library to extend the Objective-C programming language.

ashfurrow/FunctionalReactivePixels 706

A demonstration of how to use FRP with ReactiveCocoa in an iOS context using the 500px API.

jspahrsummers/enemy-of-the-state 209

My talk explaining what state is and why it's so harmful

dduan/tre 190

Tree command, improved.

dduan/DrString 148

DrString finds issues in your Swift docstrings and fixes them for you.

jspahrsummers/adt 135

Algebraic data types for Python (experimental, not actively maintained)

jspahrsummers/the-future-of-reactivecocoa 75

Presentation for RACDC 2014

jspahrsummers/Clairvoyant 61

Append-only key-value database

jspahrsummers/library-oriented-programming 57

Talk about the how/why of separating concerns into libraries

kastiglione/bazel-xcode-demo-swift-driver 52

Bazel+Xcode Demo of apple/swift-driver: Swift compiler driver reimplementation in Swift

delete branch apple/llvm-project

delete branch : lldb-Name-UnsafePointer-s-single-child-pointee

delete time in 3 days

push eventapple/llvm-project

Dave Lee

commit sha 1242ce6c8d6df81131609b33863b7f6ac113a9d1

[lldb] Name UnsafePointer's single child 'pointee'

view details

Dave Lee

commit sha 1fc743226800e2f075bf72b25a1c53a7b028551b

Merge pull request #3264 from apple/lldb-Name-UnsafePointer-s-single-child-pointee [lldb] Name UnsafePointer's single child 'pointee'

view details

push time in 3 days

PR merged apple/llvm-project

[lldb] Name UnsafePointer's single child 'pointee'

Currently, the builtin formatter for UnsafePointer and UnsafeMutablePointer provide a single child, which is named [0]. This changes that child to be named pointee. This has two advantages:

First, it enables v ptr.pointee to work, which matches p ptr.pointee. This is typically how unsafe pointers access their contents, not via subscript.

Second, it avoids a behavior that looks like a bug to the user. For example:

let ptr = UnsafeMutablePointer<Int>.allocate(capacity: 2)
ptr[0] = 41
ptr[1] = 23
print(ptr) // break here

On that last line, running v ptr produces:

(lldb) v ptr
(UnsafeMutablePointer<Int>) ptr = 0x100404080 {
  [0] = 41
}

Both UnsafePointer and UnsafeMutablePointer will only ever print the single child. A user may think their data is wrong, when it's in fact correct (because they aren't shown the second value). Or, they might think lldb has a bug, when in fact printing a single child expected behavior. Unless I have missed something, Unsafe(Mutable)?Pointer does not capture state that would indicate it was created with a specific capacity, that information is "erased". If a capacity were available at runtime, lldb could print all of the children.

Note that with this change v ptr[0] still succeeds, so that behavior is maintained. Also note that v ptr[1] does not currently work regardless of whether it's valid. This is because the provider reports only 1 child. The work around is to run p ptr[1].

After this change, the above v command prints:

(lldb) v ptr
(UnsafeMutablePointer<Int>) ptr = 0x100404080 {
  pointee = 41
}

rdar://83155374

+24 -2

4 comments

2 changed files

kastiglione

pr closed time in 3 days

pull request commentapple/llvm-project

[lldb] Name UnsafePointer's single child 'pointee'

@swift-ci test

kastiglione

comment created time in 4 days

push eventapple/llvm-project

Augusto Noronha

commit sha 824e91ca96f3ffb617869b8371f5f1245b8a44d4

[lldb] Use reflection to get the dynamic type of a class

view details

Jonas Devlieghere

commit sha d519560f0d8271f66f142c6e4ad471eabaeaada4

[lldb] Remove SBExecutionContext::reset (NFC) This is a protected function that's not implemented. (cherry picked from commit c96d45700f6d3cb2b8d1972bb8de03522b3ff8d7)

view details

Jonas Devlieghere

commit sha 2888998834f2e1ec275c010fcb6009f2b9736040

Merge pull request #3260 from apple/🍒/FBI/c96d45700f6d3cb2b8d1972bb8de03522b3ff8d7 [lldb] Remove SBExecutionContext::reset (NFC)

view details

Dan Liew

commit sha 3672975ba1a85200b2c7696b1392cbe3d7357f87

[Compiler-RT] For arm64e test suites use the SDK version as the minimum deployment target. Previously we used the minimum deployment target used for the platform (e.g. iOS is 9.0). Unfortunately this leads to ABI incompatibilities with arm64e devices running newer OSs. In particular the following TSan test cases that used libcxx would fail due to the ABI mismatch. * Darwin/libcxx-shared-ptr-recursive.mm * Darwin/libcxx-shared-ptr-stress.mm * Darwin/libcxx-shared-ptr.mm * libcxx/std_shared_ptr.cpp Given that arm64e is not ABI stable we should ideally match the deployment target for sanitizer runtimes and their tests cases to the device when building for arm64e. Unfortunately having a mixed deployment target (based on architecture) isn't currently supported by the build system and is non-trivial to implement. As a stop-gap measure this patch changes the sanitizer test suites (but not the sanitizer runtimes themselves) to use a newer deployment target when targetting arm64e. The deployment target used for arm64e is the SDK version because this "should" match the OS version running on the target device (it is a configuration error to not match them). rdar://83080611 (cherry picked from commit f4382d4b0972ac31a2027610adfb9d4dc36caa2e)

view details

Valeriy Savchenko

commit sha 0bbb6e26269dfd0dc5fff59b883fd5de5204aacb

[analyzer] Add control flow arrows to the analyzer's HTML reports This commit adds a very first version of this feature. It is off by default and has to be turned on by checking the corresponding box. For this reason, HTML reports still keep control notes (aka grey bubbles). Further on, we plan on attaching arrows to events and having all arrows not related to a currently selected event barely visible. This will help with reports where control flow goes back and forth (eg in loops). Right now, it can get pretty crammed with all the arrows. Differential Revision: https://reviews.llvm.org/D92639 (cherry picked from commit 97bcafa28deb95ad32f83fe339d78454d899ca1b)

view details

Valeriy Savchenko

commit sha 4923fb79a0497a015c1c3b3b3b3bd8527f29bf47

[analyzer] Highlight arrows for currently selected event In some cases, when the execution path of the diagnostic goes back and forth, arrows can overlap and create a mess. Dimming arrows that are not relevant at the moment, solves this issue. They are still visible, but don't draw too much attention. Differential Revision: https://reviews.llvm.org/D92928 (cherry picked from commit 9e02f58780ab8734e5d27a0138bd477d18ae64a1)

view details

Artem Dergachev

commit sha 4b835a4a68fb28508a2c096f14a97eed2726f354

[analyzer] Fix scan-build report deduplication. The previous behavior was to deduplicate reports based on md5 of the html file. This algorithm might have worked originally but right now HTML reports contain information rich enough to make them virtually always distinct which breaks deduplication entirely. The new strategy is to (finally) take advantage of IssueHash - the stable report identifier provided by clang that is the same if and only if the reports are duplicates of each other. Additionally, scan-build no longer performs deduplication on its own. Instead, the report file name is now based on the issue hash, and clang instances will silently refuse to produce a new html file when a duplicate already exists. This eliminates the problem entirely. The '-analyzer-config stable-report-filename' option is deprecated because report filenames are no longer unstable. A new option is introduced, '-analyzer-config verbose-report-filename', to produce verbose file names that look similar to the old "stable" file names. The old option acts as an alias to the new option. Differential Revision: https://reviews.llvm.org/D105167 (cherry picked from commit 73093599287cc6d546ac46652ee781789d7de61f)

view details

Artem Dergachev

commit sha 817c856799196a142fc6eb8a8e88fcfa0ffe898c

[clang-tidy] bugprone-infinite-loop: Fix false positives with volatile addresses. Low-level code may occasionally deal with direct access by concrete addresses such as 0x1234. Values at these addresses act like globals: they can change at any time. They typically wear volatile qualifiers. Suppress all warnings on loops with conditions that involve casting anything to a pointer-to-...-pointer-to-volatile type. The closely related bugprone-redundant-branch-condition check doesn't seem to be affected. Add a test just in case. Differential Revision: https://reviews.llvm.org/D108808 (cherry picked from commit dcde8fdeeb3ebda6fe6a23d933fbe5caee01c088)

view details

Augusto Noronha

commit sha ca25ed6cb45209d5e7ab60b0c9632c66a1bdb6d3

Merge pull request #3204 from augusto2112/remove-remoteast-from-GetDynamicTypeAndAddress_Class [lldb] Use reflection to get the dynamic type of a class

view details

guopeilin

commit sha 1f3bd3700247c9098bd16fad01e681c99aa6d8d8

[AArch64][GlobalISel] Use ZExtValue for zext(xor) when invert tb(n)z Currently, we use SExtValue to decide whether to invert tbz or tbnz. However, for the case zext (xor x, c), we should use ZExt rather than SExt otherwise we will generate totally opposite branches. Reviewed By: paquette Differential Revision: https://reviews.llvm.org/D108755 (cherry picked from commit 5f48c144c58f6d23e850a1978a6fe05887103b17)

view details

Alex Lorenz

commit sha 3bbb4279f62c85dd50d478a0bd2df777498b9823

Merge pull request #3208 from haoNoQ/static-analyzer-cherrypicks-21 Static analyzer cherrypicks 23

view details

Saleem Abdulrasool

commit sha d0f00c4d76d1d3d6595cb8f0ce4aca1afae87781

Target: explicitly handle `.swift1_autolink_entries` This is being applied downstream as the section is not a standard section and this is Swift centric. The longer term solution here is to drop support for gold as a linker as we have done for the BFD linker. With the use of LLD, we can use a LLVM extension to inject linker options into ELF. This has a corresponding change to Swift to remove the previous ELF specific gadget to discard the metadata. rdar://82640394

view details

Varun Gandhi

commit sha ed1a8e179a33b57ffdac5b0f7b96949679f1a00e

Turn on swiftasync for i386. (cherry picked from commit 8c462e79b60e82a758b6aa1587dc156d30c6d850) It was reverted in bcbe5a8cdbb3f3e949c565236ca181486d69f815, due to LLVM-side issues, but those should be fixed with apple/llvm-project PRs #2788 and #2790.

view details

Saleem Abdulrasool

commit sha dee18dd3f77d66c91c215973613a8b38a989fe0c

Merge pull request #3249 from compnerd/gadget-gadget Target: explicitly handle `.swift1_autolink_entries`

view details

Evan Wilde

commit sha 77865dbcbc9abb255fc8a10a4aae32ed45bb9ca3

Merge pull request #3265 from etcwilde/ewilde/rebranch/fix-i386watchos-concurrency Rebranch: Turn on swiftasync for i386.

view details

Vedant Kumar

commit sha 7b1f0cb5f36680c1e0f3f56c38cedf1a3162a21a

[MachCore] Report arm64 thread exception state A MachO userspace corefile may contain LC_THREAD commands which specify thread exception state. For arm64* only (for now), report a human-readable version of this state as the thread stop reason, instead of 'SIGSTOP'. As a follow-up, similar functionality can be implemented for x86 cores by translating the trapno/err exception registers. rdar://82898146 Differential Revision: https://reviews.llvm.org/D109795 (cherry picked from commit 3b14d80ad4af303c9f7df189b8b7eee528d0ec8d)

view details

Vedant Kumar

commit sha 16eb777b09d6fb61f197de45d67e3204af0d1f2d

Merge pull request #3269 from apple/cherry-82898146-to-20210726 [MachCore] Report arm64 thread exception state

view details

Vedant Kumar

commit sha 5966f3eb5785f9f1deb26f33c41e248646793281

[lldb][crashlog] Avoid specifying arch for image when a UUID is present When adding an image to a target for crashlog purposes, avoid specifying the architecture of the image. This has the effect of making SBTarget::AddModule infer the ArchSpec for the image based on the SBTarget's architecture, which LLDB puts serious effort into calculating correctly (in TargetList::CreateTargetInternal). The status quo is that LLDB randomly guesses the ArchSpec for a module if its architecture is specified, via: ``` SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture -> GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex ``` ... which means that the same crashlog can fail to load on an Apple Silicon Mac (due to the random guess of arm64e-apple-macosx for the module's ArchSpec not being compatible with the SBTarget's (correct) ArchSpec), while loading just fine on an Intel Mac. I'm not sure how to add a test for this (it doesn't look like there's test coverage of this path in-tree). It seems like it would be pretty complicated to regression test: the host LLDB would need to be built for arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a binary with an iOS deployment target. I'm open to other / simpler options. rdar://82679400 Differential Revision: https://reviews.llvm.org/D110013 (cherry picked from commit e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc)

view details

Vedant Kumar

commit sha 0f6e045a5eab7dfec10e1c9e1e6865f18882b205

Merge pull request #3270 from apple/cherry-82679400-to-20210726 [lldb][crashlog] Avoid specifying arch for image when a UUID is present

view details

Dave Lee

commit sha 1242ce6c8d6df81131609b33863b7f6ac113a9d1

[lldb] Name UnsafePointer's single child 'pointee'

view details

push time in 4 days

pull request commentapple/llvm-project

[lldb] Name UnsafePointer's single child 'pointee'

@swift-ci test

kastiglione

comment created time in 4 days

pull request commentapple/llvm-project

[lldb] Name UnsafePointer's single child 'pointee'

@swift-ci test

kastiglione

comment created time in 6 days

pull request commentapple/llvm-project

[lldb] Name UnsafePointer's single child 'pointee'

@swift-ci test

kastiglione

comment created time in 7 days

PR opened apple/llvm-project

[lldb] Name UnsafePointer's single child 'pointee'

The builtin formatter for UnsafePointer and UnsafeMutablePointer provide a single child, which is named [0]. This changes that child to be named pointee. This has two advantages:

First, it enables v ptr.pointee to work, which matches p ptr.pointee

Second, it avoids a behavior that looks like a bug to the user. For example:

let ptr = UnsafeMutablePointer<Int>.allocate(capacity: 2)
ptr[0] = 41
ptr[1] = 23
print(ptr) // break here

On that last line, running v ptr produces:

(lldb) v ptr
(UnsafeMutablePointer<Int>) ptr = 0x100404080 {
  [0] = 41
}

Both UnsafePointer and UnsafeMutablePointer will only ever print the single child. A user may think their data is wrong, when it's in fact correct (because they aren't shown the second value). Or, they might think lldb has a bug, when in fact printing a single child intended behavior. Unless I have missed something, Unsafe(Mutable)?Pointer does not capture state that would indicate it was created with a specific capacity, that information is "erased". If a capacity were available at runtime, lldb could print all of the children.

Note that with this change v ptr[0] still succeeds, so that behavior is maintained. Also note that v ptr[1] does not currently work regardless of whether it's valid. This is because the provider reports only 1 child. The work around is to run p ptr[1].

rdar://83155374

+24 -2

0 comment

2 changed files

pr created time in 7 days

Pull request review commentapple/llvm-project

[lldb] Adjust parse_frames for unnamed images

 def parse_frames(self, thread, json_frames):         idx = 0         for json_frame in json_frames:             image_id = int(json_frame['imageIndex'])-            ident = self.get_used_image(image_id)['name']+            json_image = self.get_used_image(image_id)+            ident = json_image['name'] if 'name' in json_image else ''

Is json_image a dict? If so, a more idiomatic way is get():

ident = json_image.get('name') or ''
JDevlieghere

comment created time in 8 days

PullRequestReviewEvent

pull request commentapple/swift

[DNM] [lit] Do not delete the cache.

in that the debugger can insert modules into the module cache that Swift normally wouldn't produce … and then Swift can't detect that there's something wrong when it loads those modules.

@beccadax I'm wondering if these are implying lldb should operate differently? Would you mind providing an example? What modules would lldb insert that Swift wouldn't normally produce? In what ways is there something wrong with the modules?

varungandhi-apple

comment created time in 16 days

pull request commentapple/swift

Add -prefix-serialized-debug-info frontend flag

See https://github.com/apple/swift/pull/17665 for a related earlier change.

rmaz

comment created time in 22 days

Pull request review commentapple/llvm-project

Cherry-pick the addition of a ThreadPlanStack mutex to release/5.5

 class ThreadPlanStackMap {    void AddThread(Thread &thread) {     lldb::tid_t tid = thread.GetID();-    m_plans_list.emplace(tid, thread);+    // If we already have a ThreadPlanStack for this thread, use it.+    if (m_plans_list.find(tid) != m_plans_list.end())+      return;++    m_plans_up_container.emplace_back(+        std::make_unique<ThreadPlanStack>(thread));+    m_plans_list.emplace(tid, m_plans_up_container.back().get());   }    bool RemoveTID(lldb::tid_t tid) {     auto result = m_plans_list.find(tid);     if (result == m_plans_list.end())       return false;-    result->second.ThreadDestroyed(nullptr);+    ThreadPlanStack *removed_stack = result->second;     m_plans_list.erase(result);+    // Now find it in the stack storage:+    auto end = m_plans_up_container.end();+    auto iter = std::find_if(m_plans_up_container.begin(), end,+        [&] (std::unique_ptr<ThreadPlanStack> &stack) {+          return stack->IsTID(tid);+        });+    if (iter == end)+      return false;

It appears this can happen (only) if one of us were to call thread plan prune <tid> with an invalid tid.

jimingham

comment created time in 25 days

PullRequestReviewEvent

Pull request review commentapple/llvm-project

Support async function calls in the expression evaluator and REPL.

+import _Concurrency+import Darwin+// Test that the pass pipeline is set up to support concurrency.+var i: Int = 0++if #available(macOS 12, iOS 15, watchOS 8, tvOS 15, *) {++  actor Actor {+    func f() -> Int { return 42 }+  }++  let queue = Actor()+  async {+    i = await queue.f()+  }++} else {+  // Still make the test pass if we don't have concurrency.+  i = 42+}++while (i == 0) { sleep(1) }

good call

adrian-prantl

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentapple/llvm-project

Support async function calls in the expression evaluator and REPL.

+import _Concurrency+// Test that the pass pipeline is set up to support concurrency.+var i: Int = 0+if #available(macOS 12, iOS 15, watchOS 8, tvOS 15, *) {+  actor Actor {+    func f() -> Int { return 42 }+  }++  let queue = Actor()+  async {+    i = await queue.f()+  }+}+i - 19

Is there a race, or do we have some guarantee by the way repl evaluates expressions, that this async block will always complete before i - 19 is evaluated?

Also I believe async { ... } is being or has been replaced with Task { ... }.

adrian-prantl

comment created time in 2 months

PullRequestReviewEvent

push eventllvm/llvm-project

Dave Lee

commit sha 41d0b20cc90f2aea25b4306f6c8f6c258ca3d377

[lldb] Avoid moving ThreadPlanSP from plans vector Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following: 1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector 2. Operate on the last plan 3. Pop the last plan off the plans vector This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack. An open question is whether this use of `std::move` was the result of a measure performance problem. Differential Revision: https://reviews.llvm.org/D106171

view details

push time in 2 months

Pull request review commentapple/swift

[Docs] Added a calling convention summary document.

+Calling Convention Summary+==========================++Below is a summary of the calling conventions used on macOS and iOS.++The `ABI stability manifesto <../ABIStabilityManifesto.md>`_ gives more details+on the use of the Swift error return and ``self`` registers, while `The Swift+Calling Convention <CallingConvention.rst>`_ covers the specifics in more+details.  (The Swift ``self`` register is known in other documents as the+"Context register".)++x86-64+------++See `Apple x86-64 Documentation`_, `System V ABI AMD64 Processor Supplement`_.++.. _Apple x86-64 Documentation: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/LowLevelABI/140-x86-64_Function_Calling_Conventions/x86_64.html+.. _System V ABI AMD64 Processor Supplement: https://www.uclibc.org/docs/psABI-x86_64.pdf++Register usage+^^^^^^^^^^^^^^+++-----------+----------------------------------+----------+----------+----------++| Register  | Purpose                          | C++      | ObjC     | Swift    |++===========+==================================+==========+==========+==========++| ``rax``   | Return value; also, for varargs, |          |          |          |+|           | number of ``xmm`` registers used |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``rbx``   | Callee-saved register            |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``rdi``   | Integer argument 1               | ``this`` | ``self`` |          |++-----------+----------------------------------+----------+----------+----------++| ``rsi``   | Integer argument 2               |          | ``_cmd`` |          |++-----------+----------------------------------+----------+----------+----------++| ``rdx``   | Integer argument 3               |          |          |          |+|           | (2nd return value)               |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``rcx``   | Integer argument 4               |          |          |          |+|           | (3rd return value)               |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``r8``    | Integer argument 5               |          |          |          |+|           | (4th return value)               |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``r9``    | Integer argument 6               |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``r12``   | Callee-saved register            |          |          | Error    |+|           |                                  |          |          | return   |++-----------+----------------------------------+----------+----------+----------++| ``r13``   | Callee-saved register            |          |          | ``self`` |++-----------+----------------------------------+----------+----------+----------++| ``r14``   | Callee-saved register            |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``r15``   | Callee-saved register            |          |          |          |+|           | (other platforms use as GOT ptr) |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``st0``   | Used to return ``long double``   |          |          |          |+|           | values                           |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``st1``   | Used to return ``long double``   |          |          |          |+|           | values                           |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``xmm0``- | Floating point arguments 1-8     |          |          |          |+| ``xmm7``  | (``xmm0``-``xmm3`` also used     |          |          |          |+|           | for return)                      |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``rsp``   | Stack pointer                    |          |          |          |++-----------+----------------------------------+----------+----------+----------++| ``rbp``   | Callee-saved register,           |          |          |          |+|           | used as frame pointer            |          |          |          |++-----------+----------------------------------+----------+----------+----------+++Stack frame+^^^^^^^^^^^++On function entry, ``sp+8`` is **16-byte aligned**, i.e. the start of the memory+arguments is 16-byte aligned.+++---------------+---------------+------------------------++|               | ``rbp+8n+16`` | memory argument *n*    |+|               |               |                        |+|               | ...           | ...                    |+|               |               |                        |+|               | ``rbp+16``    | memory argument 0      |++---------------+-----------+---+------------------------++| ↓ Current Frame           |           ↑ Previous Frame |++---------------+-----------+---+------------------------++|               | ``rbp+8``     | return address         |+|               |               |                        |++---------------+---------------+------------------------++| entry ``rsp`` | ``rbp``       | previous ``rbp`` value |++---------------+---------------+------------------------++|               | ``rbp-8``     |                        |+|               |               |                        |+|               | ...           |      local storage     |+|               |               |                        |+|               | ``rsp``       |                        |++---------------+---------------+------------------------++|               | ``rsp-8``     |                        |+|               |               |                        |+|               | ...           |        red zone        |+|               |               |                        |+|               | ``rsp-128``   |                        |++---------------+---------------+------------------------+++ARM64+-----++See `Apple ARM64 Documentation`_, `Procedure Call Standard for the Arm 64-bit Architecture`_.++.. _Apple ARM64 Documentation: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms+.. _Procedure Call Standard for the Arm 64-bit Architecture: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst++Register usage+^^^^^^^^^^^^^^+++----------+---------+-------------------------+----------+----------+----------++| Register | Special | Purpose                 | C++      | ObjC     | Swift    |++==========+=========+=========================+==========+==========+==========++| ``x0``   |         | Integer argument 1      | ``this`` | ``self`` |          |+|          |         | (1st return value)      |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x1``   |         | Integer argument 2      |          | ``_cmd`` |          |+|          |         | (2nd return value)      |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x2``-  |         | Integer arguments 3-8   |          |          |          |+| ``x7``   |         | (3rd-8th return values) |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x8``   |         | Indirect result         |          |          |          |+|          |         | location register       |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x16``  | ``ip0`` | Scratch registers (used |          |          |          |++----------+---------+ by dyld, can be used    |          |          |          |+| ``x17``  | ``ip1`` | freely otherwise)       |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x18``  |         | RESERVED **DO NOT USE** |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x19``  |         | Callee-saved register   |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x20``  |         | Callee-saved register   |          |          | ``self`` |++----------+---------+-------------------------+----------+----------+----------++| ``x21``  |         | Callee-saved register   |          |          | Error    |+|          |         |                         |          |          | return   |++----------+---------+-------------------------+----------+----------+----------++| ``x22``- |         | Callee-saved registers  |          |          |          |+| ``x28``  |         |                         |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x29``  | ``fp``  | Frame pointer           |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``x30``  | ``lr``  | Link register           |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``sp``   |         | Stack pointer           |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``v0``-  |         | Floating point/SIMD     |          |          |          |+| ``v7``   |         | arguments 1-8           |          |          |          |+|          |         | (also for return)       |          |          |          |++----------+---------+-------------------------+----------+----------+----------++| ``v8``-  |         | Callee-saved registers  |          |          |          |+| ``v15``  |         | (**lower 64-bits only**)|          |          |          |++----------+---------+-------------------------+----------+----------+----------+++Stack frame+^^^^^^^^^^^++The stack pointer is **16-byte aligned**.+++--------------+---------------+------------------------++|              | ``fp+8n+16``  | last memory argument   |+|              |               |                        |+|              | ...           | ...                    |+|              |               |                        |+|              | ``fp+16``     | memory argument 0 [1]_ |++--------------+------------+--+------------------------++| ↓ Current Frame           |          ↑ Previous Frame |++--------------+------------+--+------------------------++| entry ``sp`` | ``fp+8``      | saved ``lr``           |

have you considered documenting the "entry sp" in the table's header? Does it simplify the table to get rid of this one almost empty column?

al45tair

comment created time in 2 months

PullRequestReviewEvent

push eventapple/llvm-project

Dave Lee

commit sha 864ea96a93775d04dce85ca1719be3b1e6eb3b2c

[lldb] Handle suspend resume partial functions in TestSwiftStepInAsync (#2846) (cherry picked from commit a8faa34aac5bfacdfbd16ec1465436e86843f1a2)

view details

push time in 2 months

push eventapple/llvm-project

Dave Lee

commit sha cfb553a5408ffaa9785f7e7b820bdb0c10eb340c

[lldb] Fix #if to #ifdef in Driver (NFC) (cherry picked from commit 85071e5ced45b287d4cba5d69356ba4f07852616)

view details

push time in 2 months

push eventapple/llvm-project

Dave Lee

commit sha 18ed5dff17acbfb0557d5453c00ad8e03a10188a

[lldb] Disable Stepper/TestSwiftBenchmarkOnone (cherry picked from commit b6e9652eae3024cad517fd820380f2260f808f99)

view details

push time in 2 months

push eventapple/llvm-project

Dave Lee

commit sha ff2cbf85ee9a40e44e6575df3913c03f83586057

use FLAKYPASS (cherry picked from commit ab3c3f18aa75c6aef3efbb3de29eb3d267f451e5)

view details

push time in 2 months

push eventapple/llvm-project

Dave Lee

commit sha 82e8fccf307a12b920eb555d41b988a5d4d8f5c7

[lldb] Add work around handling of recursive_mutex lock failures (cherry picked from commit 5a2f2108df51c5ae669be54f728c876b486f0be4)

view details

push time in 2 months

push eventapple/llvm-project

Dave Lee

commit sha 76200f07958871e7a069bcf8e4ef0b2d6b1ffe58

[lldb] Add checks before dereferencing (NFC) (cherry picked from commit c54764055dc4fb8a3d81d83898efa4fc6250b788)

view details

push time in 2 months