Related
I would like to call something like nanosleep from assembly, using only SVC calls. But it is not obvious how to do it using only the limited information I have, this list of macos syscall call signatures:
https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master
I tried to figure out what C does when calling nanosleep and I was able to reduce it to this:
struct timespec { long tv_sec; long tv_nsec; };
int nanosleep(const struct timespec *__rqtp, struct timespec *__rmtp)
__asm("_" "nanosleep" );
int main() {
struct timespec remaining, request = { 3, 1 };
int response = nanosleep(&request, &remaining); }
I am not sure what that __asm does as that does not look like assembly. Anyway I found an implementation of nanosleep in Apples libc source code. It relies on a call to clock_get_time though and that isn't defined in libc. I found a mention of clock_get_time in the XNU source code, but this is in a .defs file, which I don't know what is and it doesn't seem have an implementation.
In any case, is there some better documentation on the SVC calls, or some place I can find the assembly for the libc SVC implementation?
Any information or ideas are much appreciated.
First off, let's get the title of your question out of the way. The way you call nanosleep from assembly is like this:
mov x8, 3
stp x8, xzr, [sp, -0x10]! // 3 seconds, 0 nanoseconds
mov x0, sp
mov x1, 0
bl _nanosleep
add sp, sp, 0x10
You just use the libc implementation. For most purposes, you really shouldn't go to a deeper level, since a) on arm64 you're forced by the OS to link against libSystem (and thus libc) anyway, and b) because the Darwin kernel ABI(s) are not stable.
That said, let's look at how it works under the hood.
In the latest Libc source drop, we find that there's actually two implementations of nanosleep in gen/nanosleep.c: one for #if __DARWIN_UNIX03, which uses clock_get_time, and one for the other case, which uses mach_absolute_time and mach_wait_until. The one actually used in production is the former:
int nanosleep(const struct timespec *requested_time, struct timespec *remaining_time) {
kern_return_t kret;
int ret;
mach_timespec_t current;
mach_timespec_t completion;
if (__unix_conforming == 0)
__unix_conforming = 1;
#ifdef VARIANT_CANCELABLE
pthread_testcancel();
#endif /* VARIANT_CANCELABLE */
if ((requested_time == NULL) || (requested_time->tv_sec < 0) || (requested_time->tv_nsec >= NSEC_PER_SEC)) {
errno = EINVAL;
return -1;
}
if (remaining_time != NULL) {
/* once we add requested_time, this will be the completion time */
kret = clock_get_time(clock_port, &completion);
if (kret != KERN_SUCCESS) {
fprintf(stderr, "clock_get_time() failed: %s\n", mach_error_string(kret));
errno = EINVAL;
return -1;
}
}
ret = SEMWAIT_SIGNAL(clock_sem, MACH_PORT_NULL, 1, 1, (int64_t)requested_time->tv_sec, (int32_t)requested_time->tv_nsec);
if (ret < 0) {
if (errno == ETIMEDOUT) {
return 0;
} else if (errno == EINTR) {
if (remaining_time != NULL) {
ret = clock_get_time(clock_port, ¤t);
if (ret != KERN_SUCCESS) {
fprintf(stderr, "clock_get_time() failed: %s\n", mach_error_string(ret));
return -1;
}
/* This depends on the layout of a mach_timespec_t and timespec_t being equivalent */
ADD_MACH_TIMESPEC(&completion, requested_time);
/* We have to compare first, since mach_timespect_t contains unsigned integers */
if(CMP_MACH_TIMESPEC(&completion, ¤t) > 0) {
SUB_MACH_TIMESPEC(&completion, ¤t);
remaining_time->tv_sec = completion.tv_sec;
remaining_time->tv_nsec = completion.tv_nsec;
} else {
bzero(remaining_time, sizeof(*remaining_time));
}
}
} else {
errno = EINVAL;
}
}
return -1;
}
This ends up in /usr/lib/system/libsystem_c.dylib (re-exported by /usr/lib/libSystem.B.dylib). We can look at the assembly by either using dlopen/dlsym to dump the bytes, extracting the dylib from the dyld_shared_cache, or grabbing it from the ramdisk:
;-- _nanosleep:
0x0000e4d4 7f2303d5 pacibsp
0x0000e4d8 ff0301d1 sub sp, sp, 0x40
0x0000e4dc f44f02a9 stp x20, x19, [sp, 0x20]
0x0000e4e0 fd7b03a9 stp x29, x30, [sp, 0x30]
0x0000e4e4 fdc30091 add x29, sp, 0x30
0x0000e4e8 f30301aa mov x19, x1
0x0000e4ec f40300aa mov x20, x0
0x0000e4f0 ff7f01a9 stp xzr, xzr, [sp, 0x10]
0x0000e4f4 a80300d0 adrp x8, reloc.__unix_conforming
0x0000e4f8 080140f9 ldr x8, [x8]
0x0000e4fc 090140b9 ldr w9, [x8]
0x0000e500 69000035 cbnz w9, 0xe50c
0x0000e504 29008052 mov w9, 1
0x0000e508 090100b9 str w9, [x8]
0x0000e50c e5b00194 bl sym.imp.pthread_testcancel
0x0000e510 140300b4 cbz x20, 0xe570
0x0000e514 840240f9 ldr x4, [x20]
0x0000e518 c402f8b7 tbnz x4, 0x3f, 0xe570
0x0000e51c 850640f9 ldr x5, [x20, 8]
0x0000e520 08409952 mov w8, 0xca00
0x0000e524 4873a772 movk w8, 0x3b9a, lsl 16
0x0000e528 bf0008eb cmp x5, x8
0x0000e52c 22020054 b.hs 0xe570
0x0000e530 330300b4 cbz x19, 0xe594
0x0000e534 48040090 adrp x8, 0x96000
0x0000e538 08112c91 add x8, x8, 0xb04
0x0000e53c 000140b9 ldr w0, [x8]
0x0000e540 e1430091 add x1, sp, 0x10
0x0000e544 c7ae0194 bl sym.imp.clock_get_time
0x0000e548 40020034 cbz w0, 0xe590
0x0000e54c 080400d0 adrp x8, sym._gCRAnnotations
0x0000e550 08210f91 add x8, x8, 0x3c8
0x0000e554 130140f9 ldr x19, [x8]
0x0000e558 c2af0194 bl sym.imp.mach_error_string
0x0000e55c e00300f9 str x0, [sp]
0x0000e560 610300f0 adrp x1, 0x7d000
0x0000e564 21682b91 add x1, x1, 0xada
0x0000e568 e00313aa mov x0, x19
0x0000e56c 73100094 bl sym._fprintf
0x0000e570 84ad0194 bl sym.imp.__error
0x0000e574 c8028052 mov w8, 0x16
0x0000e578 080000b9 str w8, [x0]
0x0000e57c 00008012 mov w0, -1
0x0000e580 fd7b43a9 ldp x29, x30, [sp, 0x30]
0x0000e584 f44f42a9 ldp x20, x19, [sp, 0x20]
0x0000e588 ff030191 add sp, sp, 0x40
0x0000e58c ff0f5fd6 retab
0x0000e590 841640a9 ldp x4, x5, [x20]
0x0000e594 48040090 adrp x8, 0x96000
0x0000e598 08012c91 add x8, x8, 0xb00
0x0000e59c 000140b9 ldr w0, [x8]
0x0000e5a0 01008052 mov w1, 0
0x0000e5a4 22008052 mov w2, 1
0x0000e5a8 23008052 mov w3, 1
0x0000e5ac d1ad0194 bl sym.imp.__semwait_signal
0x0000e5b0 60feff36 tbz w0, 0x1f, 0xe57c
0x0000e5b4 73ad0194 bl sym.imp.__error
0x0000e5b8 080040b9 ldr w8, [x0]
0x0000e5bc 1ff10071 cmp w8, 0x3c
0x0000e5c0 61000054 b.ne 0xe5cc
0x0000e5c4 00008052 mov w0, 0
0x0000e5c8 eeffff17 b 0xe580
0x0000e5cc 6dad0194 bl sym.imp.__error
0x0000e5d0 080040b9 ldr w8, [x0]
0x0000e5d4 1f110071 cmp w8, 4
0x0000e5d8 c1fcff54 b.ne 0xe570
0x0000e5dc 13fdffb4 cbz x19, 0xe57c
0x0000e5e0 48040090 adrp x8, 0x96000
0x0000e5e4 08112c91 add x8, x8, 0xb04
0x0000e5e8 000140b9 ldr w0, [x8]
0x0000e5ec e1630091 add x1, sp, 0x18
0x0000e5f0 9cae0194 bl sym.imp.clock_get_time
0x0000e5f4 60010034 cbz w0, 0xe620
0x0000e5f8 080400d0 adrp x8, sym._gCRAnnotations
0x0000e5fc 08210f91 add x8, x8, 0x3c8
0x0000e600 130140f9 ldr x19, [x8]
0x0000e604 97af0194 bl sym.imp.mach_error_string
0x0000e608 e00300f9 str x0, [sp]
0x0000e60c 610300f0 adrp x1, 0x7d000
0x0000e610 21682b91 add x1, x1, 0xada
0x0000e614 e00313aa mov x0, x19
0x0000e618 48100094 bl sym._fprintf
0x0000e61c d8ffff17 b 0xe57c
0x0000e620 ea3f9952 mov w10, 0xc9ff
0x0000e624 4a73a772 movk w10, 0x3b9a, lsl 16
0x0000e628 880a40b9 ldr w8, [x20, 8]
0x0000e62c ec274229 ldp w12, w9, [sp, 0x10]
0x0000e630 0bc08652 mov w11, 0x3600
0x0000e634 ab8cb872 movk w11, 0xc465, lsl 16
0x0000e638 2801080b add w8, w9, w8
0x0000e63c 09010b0b add w9, w8, w11
0x0000e640 1f010a6b cmp w8, w10
0x0000e644 2bc1881a csel w11, w9, w8, gt
0x0000e648 89d58c1a cinc w9, w12, gt
0x0000e64c 8c0240b9 ldr w12, [x20]
0x0000e650 e81b40b9 ldr w8, [sp, 0x18]
0x0000e654 29010c0b add w9, w9, w12
0x0000e658 3f01086b cmp w9, w8
0x0000e65c 69000054 b.ls 0xe668
0x0000e660 ec1f40b9 ldr w12, [sp, 0x1c]
0x0000e664 05000014 b 0xe678
0x0000e668 c3010054 b.lo 0xe6a0
0x0000e66c ec1f40b9 ldr w12, [sp, 0x1c]
0x0000e670 7f010c6b cmp w11, w12
0x0000e674 6d010054 b.le 0xe6a0
0x0000e678 6b010c6b subs w11, w11, w12
0x0000e67c a5000054 b.pl 0xe690
0x0000e680 4a010b0b add w10, w10, w11
0x0000e684 4b050011 add w11, w10, 1
0x0000e688 29050051 sub w9, w9, 1
0x0000e68c e92f0229 stp w9, w11, [sp, 0x10]
0x0000e690 2801084b sub w8, w9, w8
0x0000e694 697d4093 sxtw x9, w11
0x0000e698 682600a9 stp x8, x9, [x19]
0x0000e69c b8ffff17 b 0xe57c
0x0000e6a0 7f7e00a9 stp xzr, xzr, [x19]
0x0000e6a4 b6ffff17 b 0xe57c
I don't think this is something you really want to implement yourself.
But either way, you noticed that it uses clock_get_time, which is not defined in that library. Indeed clock_get_time is in /usr/lib/system/libsystem_kernel.dylib:
;-- _clock_get_time:
0x00006440 7f2303d5 pacibsp
0x00006444 ff8301d1 sub sp, sp, 0x60
0x00006448 f44f04a9 stp x20, x19, [sp, 0x40]
0x0000644c fd7b05a9 stp x29, x30, [sp, 0x50]
0x00006450 fd430191 add x29, sp, 0x50
0x00006454 f30301aa mov x19, x1
0x00006458 f40300aa mov x20, x0
0x0000645c ff7f02a9 stp xzr, xzr, [sp, 0x20]
0x00006460 ff3b00b9 str wzr, [sp, 0x38]
0x00006464 ff1b00f9 str xzr, [sp, 0x30]
0x00006468 f5eaff97 bl sym._mig_get_reply_port
0x0000646c 480100f0 adrp x8, 0x31000
0x00006470 008547fd ldr d0, [x8, 0xf08]
0x00006474 e00700fd str d0, [sp, 8]
0x00006478 f4030229 stp w20, w0, [sp, 0x10]
0x0000647c 480100f0 adrp x8, 0x31000
0x00006480 008947fd ldr d0, [x8, 0xf10]
0x00006484 e00f00fd str d0, [sp, 0x18]
0x00006488 057c60d3 lsl x5, x0, 0x20
0x0000648c e303142a mov w3, w20
0x00006490 037c60b3 bfi x3, x0, 0x20, 0x20
0x00006494 e0230091 add x0, sp, 8
0x00006498 610080d2 mov x1, 3
0x0000649c 4100c0f2 movk x1, 2, lsl 32
0x000064a0 62a282d2 mov x2, 0x1513
0x000064a4 0203c0f2 movk x2, 0x18, lsl 32
0x000064a8 047dc0d2 mov x4, 0x3e800000000
0x000064ac 86068052 mov w6, 0x34
0x000064b0 070080d2 mov x7, 0
0x000064b4 e8300094 bl sym._mach_msg2_internal
0x000064b8 f40300aa mov x20, x0
0x000064bc c8ff9f52 mov w8, 0xfffe
0x000064c0 e8ffbd72 movk w8, 0xefff, lsl 16
0x000064c4 0800080b add w8, w0, w8
0x000064c8 1f390071 cmp w8, 0xe
0x000064cc 29008052 mov w9, 1
0x000064d0 2821c81a lsl w8, w9, w8
0x000064d4 69008852 mov w9, 0x4003
0x000064d8 0801090a and w8, w8, w9
0x000064dc 0499407a ccmp w8, 0, 4, ls
0x000064e0 21040054 b.ne 0x6564
0x000064e4 94020035 cbnz w20, 0x6534
0x000064e8 e81f40b9 ldr w8, [sp, 0x1c]
0x000064ec 1f1d0171 cmp w8, 0x47
0x000064f0 80020054 b.eq 0x6540
0x000064f4 1f311171 cmp w8, 0x44c
0x000064f8 81020054 b.ne 0x6548
0x000064fc e80b40b9 ldr w8, [sp, 8]
0x00006500 c802f837 tbnz w8, 0x1f, 0x6558
0x00006504 e80f40b9 ldr w8, [sp, 0xc]
0x00006508 1fb10071 cmp w8, 0x2c
0x0000650c 20020054 b.eq 0x6550
0x00006510 1f910071 cmp w8, 0x24
0x00006514 21020054 b.ne 0x6558
0x00006518 e82b40b9 ldr w8, [sp, 0x28]
0x0000651c e91340b9 ldr w9, [sp, 0x10]
0x00006520 3f010071 cmp w9, 0
0x00006524 0409407a ccmp w8, 0, 4, eq
0x00006528 69258012 mov w9, -0x12c
0x0000652c 1411891a csel w20, w8, w9, ne
0x00006530 0b000014 b 0x655c
0x00006534 e01740b9 ldr w0, [sp, 0x14]
0x00006538 9bf6ff97 bl sym._mig_dealloc_reply_port
0x0000653c 0a000014 b 0x6564
0x00006540 74268012 mov w20, -0x134
0x00006544 06000014 b 0x655c
0x00006548 94258012 mov w20, -0x12d
0x0000654c 04000014 b 0x655c
0x00006550 e81340b9 ldr w8, [sp, 0x10]
0x00006554 28010034 cbz w8, 0x6578
0x00006558 74258012 mov w20, -0x12c
0x0000655c e0230091 add x0, sp, 8
0x00006560 9dedff97 bl sym._mach_msg_destroy
0x00006564 e00314aa mov x0, x20
0x00006568 fd7b45a9 ldp x29, x30, [sp, 0x50]
0x0000656c f44f44a9 ldp x20, x19, [sp, 0x40]
0x00006570 ff830191 add sp, sp, 0x60
0x00006574 ff0f5fd6 retab
0x00006578 f42b40b9 ldr w20, [sp, 0x28]
0x0000657c 14ffff35 cbnz w20, 0x655c
0x00006580 e8c342f8 ldur x8, [sp, 0x2c]
0x00006584 680200f9 str x8, [x19]
0x00006588 f7ffff17 b 0x6564
Again, likely something you wouldn't want to implement by yourself in assembly.
But where does this implementation come from? You already discovered that XNU only contains a .defs file. That file is a MIG (Mach Interface Generator) definitions file, which can be used to generate both client- and server-side code. To do that, you use the mig utility shipped with Xcode (also open source). For the clocks file, the invocation would look something like this:
mig -novouchers -DLIBSYSCALL_INTERFACE=1 -DPRIVATE=1 -DKERNEL_SERVER=1 -arch arm64e xnu-8792.61.2/osfmk/mach/clock.defs
That will generate a clock.h, clockServer.c and clockUser.c. We only care about the last one, as it contains the userland code for clock_get_time:
/* Routine clock_get_time */
mig_external kern_return_t clock_get_time
(
clock_serv_t clock_serv,
mach_timespec_t *cur_time
)
{
#ifdef __MigPackStructs
#pragma pack(push, 4)
#endif
typedef struct {
mach_msg_header_t Head;
} Request __attribute__((unused));
#ifdef __MigPackStructs
#pragma pack(pop)
#endif
#ifdef __MigPackStructs
#pragma pack(push, 4)
#endif
typedef struct {
mach_msg_header_t Head;
NDR_record_t NDR;
kern_return_t RetCode;
mach_timespec_t cur_time;
mach_msg_trailer_t trailer;
} Reply __attribute__((unused));
#ifdef __MigPackStructs
#pragma pack(pop)
#endif
#ifdef __MigPackStructs
#pragma pack(push, 4)
#endif
typedef struct {
mach_msg_header_t Head;
NDR_record_t NDR;
kern_return_t RetCode;
mach_timespec_t cur_time;
} __Reply __attribute__((unused));
#ifdef __MigPackStructs
#pragma pack(pop)
#endif
/*
* typedef struct {
* mach_msg_header_t Head;
* NDR_record_t NDR;
* kern_return_t RetCode;
* } mig_reply_error_t;
*/
union {
Request In;
Reply Out;
} Mess;
Request *InP = &Mess.In;
Reply *Out0P = &Mess.Out;
mach_msg_return_t msg_result;
#ifdef __MIG_check__Reply__clock_get_time_t__defined
kern_return_t check_result;
#endif /* __MIG_check__Reply__clock_get_time_t__defined */
__DeclareSendRpc(1000, "clock_get_time")
InP->Head.msgh_reply_port = mig_get_reply_port();
InP->Head.msgh_bits =
MACH_MSGH_BITS(19, MACH_MSG_TYPE_MAKE_SEND_ONCE);
InP->Head.msgh_size = (mach_msg_size_t)sizeof(Request);
InP->Head.msgh_request_port = clock_serv;
InP->Head.msgh_id = 1000;
InP->Head.msgh_reserved = 0;
__BeforeSendRpc(1000, "clock_get_time")
msg_result = mach_msg(&InP->Head, MACH_SEND_MSG|MACH_RCV_MSG|MACH_MSG_OPTION_NONE, (mach_msg_size_t)sizeof(Request), (mach_msg_size_t)sizeof(Reply), InP->Head.msgh_reply_port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
__AfterSendRpc(1000, "clock_get_time")
if (msg_result != MACH_MSG_SUCCESS) {
__MachMsgErrorWithoutTimeout(msg_result);
}
if (msg_result != MACH_MSG_SUCCESS) {
{ return msg_result; }
}
#if defined(__MIG_check__Reply__clock_get_time_t__defined)
check_result = __MIG_check__Reply__clock_get_time_t((__Reply__clock_get_time_t *)Out0P);
if (check_result != MACH_MSG_SUCCESS) {
mach_msg_destroy(&Out0P->Head);
{ return check_result; }
}
#endif /* defined(__MIG_check__Reply__clock_get_time_t__defined) */
*cur_time = Out0P->cur_time;
return KERN_SUCCESS;
}
(I omitted __MIG_check__Reply__clock_get_time_t here, but it is generated in the same file, right above that function.)
One thing of note here is the call to mach_msg though. In the assembly, we can see mach_msg2_internal being invoked, but the generated code simply calls mach_msg. If you took that code as-is and tried to run it on macOS 13 or iOS 16, it would not work. The reasons for this tie deeply into the security internals of Darwin and into a mitigation shipped in the most recent major release of Apple OSes. If you're interested in the story behind that, Luca Todesco covered that in his Hexacon presentation not long ago.
But by passing -DKERNEL_SERVER=1 to mig, we actually made it generate a little stub for us at the beginning of the file:
#include <TargetConditionals.h>
#if defined(MACH_SEND_AUX_TOO_SMALL) && (defined(__arm64__) || defined(__LP64__))
#undef mach_msg
#define mach_msg mig_mach_msg
static inline mach_msg_return_t
mig_mach_msg(
mach_msg_header_t *msg,
mach_msg_option_t option,
mach_msg_size_t send_size,
mach_msg_size_t rcv_size,
mach_port_name_t rcv_name,
mach_msg_timeout_t timeout,
mach_port_name_t notify)
{
(void)notify;
return mach_msg2(msg, option | MACH64_SEND_KOBJECT_CALL,
*msg, send_size, rcv_size, rcv_name, timeout, 0);
}
#endif
mach_msg2 isn't defined in the public SDK either (and is not a symbol in any library), but we can steal it together from osfmk/mach/message.h in XNU source:
typedef uint64_t mach_msg_option64_t;
#define MACH64_SEND_MSG MACH_SEND_MSG
#define MACH64_MSG_VECTOR 0x0000000100000000ull
#define MACH64_SEND_KOBJECT_CALL 0x0000000200000000ull
#if defined(__LP64__) || defined(__arm64__)
__API_AVAILABLE(macos(13.0), ios(16.0), tvos(16.0), watchos(9.0))
__IOS_PROHIBITED __WATCHOS_PROHIBITED __TVOS_PROHIBITED
extern mach_msg_return_t mach_msg2_internal(
void *data,
mach_msg_option64_t option64,
uint64_t msgh_bits_and_send_size,
uint64_t msgh_remote_and_local_port,
uint64_t msgh_voucher_and_id,
uint64_t desc_count_and_rcv_name,
uint64_t rcv_size_and_priority,
uint64_t timeout);
__API_AVAILABLE(macos(13.0), ios(16.0), tvos(16.0), watchos(9.0))
__IOS_PROHIBITED __WATCHOS_PROHIBITED __TVOS_PROHIBITED
static inline mach_msg_return_t
mach_msg2(
void *data,
mach_msg_option64_t option64,
mach_msg_header_t header,
mach_msg_size_t send_size,
mach_msg_size_t rcv_size,
mach_port_t rcv_name,
uint64_t timeout,
uint32_t priority)
{
mach_msg_base_t *base;
mach_msg_size_t descriptors;
if (option64 & MACH64_MSG_VECTOR) {
base = (mach_msg_base_t *)((mach_msg_vector_t *)data)->msgv_data;
} else {
base = (mach_msg_base_t *)data;
}
if ((option64 & MACH64_SEND_MSG) &&
(base->header.msgh_bits & MACH_MSGH_BITS_COMPLEX)) {
descriptors = base->body.msgh_descriptor_count;
} else {
descriptors = 0;
}
#define MACH_MSG2_SHIFT_ARGS(lo, hi) ((uint64_t)hi << 32 | (uint32_t)lo)
return mach_msg2_internal(data, option64,
MACH_MSG2_SHIFT_ARGS(header.msgh_bits, send_size),
MACH_MSG2_SHIFT_ARGS(header.msgh_remote_port, header.msgh_local_port),
MACH_MSG2_SHIFT_ARGS(header.msgh_voucher_port, header.msgh_id),
MACH_MSG2_SHIFT_ARGS(descriptors, rcv_name),
MACH_MSG2_SHIFT_ARGS(rcv_size, priority), timeout);
#undef MACH_MSG2_SHIFT_ARGS
}
#endif
This then goes through mach_msg2_internal, which is defined in libsyscall/mach/mach_msg.c and compiled into libsystem_kernel.dylib, and that calls down to mach_msg2_trap, which, at long long last, is where the svc happens:
;-- _mach_msg2_trap:
0x00000d68 d0058092 mov x16, -0x2f
0x00000d6c 011000d4 svc 0x80
0x00000d70 c0035fd6 ret
I guess with this you could build your own nanosleep on macOS 13 or iOS 16 now. It wouldn't work on versions before those though (you'd have to use plain mach_msg there), and an implementation that did work on those wouldn't work on macOS 13 and iOS 16, so you probably really shouldn't. Just call the libc implementation.
It appears that the usual approach to calling printf from aarch64 asm code that works just fine on Linux does not work on MacOS running on the Apple M1.
Is there any documentation that explains what has changed?
I find that the parameters that I put in x0..x2 are getting garbled in the printf output.
The Darwin arm64 ABI passes all varags arguments on the stack, each padded to the next multiple of 8 bytes. (Types that don't fit into 8 bytes have a pointer passed instead. Regular arguments that don't fit into x0-x7/q0-q7 come before varargs on the stack, naturally aligned.)
Here's a simple example:
.globl _main
.align 2
_main:
stp x29, x30, [sp, -0x10]!
sub sp, sp, 0x10
mov x8, 66
str x8, [sp]
adr x0, Lstr
bl _printf
mov w0, 0
add sp, sp, 0x10
ldp x29, x30, [sp], 0x10
ret
Lstr:
.asciz "test: %x\n"
Note that this is different from non-varargs arguments to unprototyped functions that are passed on the stack, which are only padded up to 4 bytes (sizeof(int)). The following code:
#include <stdio.h>
#include <stdint.h>
extern void func();
__asm__
(
"_func:\n"
" ret\n"
);
int main(void)
{
uint8_t a = 1,
b = 2,
c = 3;
printf("%hhx %hhx %hhx %hhx %hhx %hhx\n", a, b, c, a, b, c);
func(a, b, c, a, b, c, a, b, c, a, b, c);
return 0;
}
compiles down to this with -O2:
;-- _main:
0x100003ee8 ff0301d1 sub sp, sp, 0x40
0x100003eec fd7b03a9 stp x29, x30, [sp, 0x30]
0x100003ef0 fdc30091 add x29, sp, 0x30
0x100003ef4 68008052 mov w8, 3
0x100003ef8 49008052 mov w9, 2
0x100003efc e92302a9 stp x9, x8, [sp, 0x20]
0x100003f00 2a008052 mov w10, 1
0x100003f04 e82b01a9 stp x8, x10, [sp, 0x10]
0x100003f08 ea2700a9 stp x10, x9, [sp]
0x100003f0c 20040010 adr x0, str._hhx__hhx__hhx__hhx__hhx__hhx_n
0x100003f10 1f2003d5 nop
0x100003f14 13000094 bl sym.imp.printf
0x100003f18 480080d2 mov x8, 2
0x100003f1c 6800c0f2 movk x8, 3, lsl 32
0x100003f20 690080d2 mov x9, 3
0x100003f24 2900c0f2 movk x9, 1, lsl 32
0x100003f28 e92300a9 stp x9, x8, [sp]
0x100003f2c 20008052 mov w0, 1
0x100003f30 41008052 mov w1, 2
0x100003f34 62008052 mov w2, 3
0x100003f38 23008052 mov w3, 1
0x100003f3c 44008052 mov w4, 2
0x100003f40 65008052 mov w5, 3
0x100003f44 26008052 mov w6, 1
0x100003f48 47008052 mov w7, 2
0x100003f4c e6ffff97 bl sym._func
0x100003f50 00008052 mov w0, 0
0x100003f54 fd7b43a9 ldp x29, x30, [sp, 0x30]
0x100003f58 ff030191 add sp, sp, 0x40
0x100003f5c c0035fd6 ret
Giving the function an actual prototype allows the removal of any padding (except the one that serves alignment purposes), like so (note the last argument being 8 bytes):
extern void func(uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint8_t,
uint8_t, uint8_t, uint8_t, uint8_t, uint8_t, uint64_t);
The code then compiles down to:
;-- _main:
0x100003ee4 ff4301d1 sub sp, sp, 0x50
0x100003ee8 f44f03a9 stp x20, x19, [sp, 0x30]
0x100003eec fd7b04a9 stp x29, x30, [sp, 0x40]
0x100003ef0 fd030191 add x29, sp, 0x40
0x100003ef4 73008052 mov w19, 3
0x100003ef8 54008052 mov w20, 2
0x100003efc f44f02a9 stp x20, x19, [sp, 0x20]
0x100003f00 28008052 mov w8, 1
0x100003f04 f32301a9 stp x19, x8, [sp, 0x10]
0x100003f08 e85300a9 stp x8, x20, [sp]
0x100003f0c 20040010 adr x0, str._hhx__hhx__hhx__hhx__hhx__hhx_n
0x100003f10 1f2003d5 nop
0x100003f14 13000094 bl sym.imp.printf
0x100003f18 68208052 mov w8, 0x103
0x100003f1c f30700f9 str x19, [sp, 8]
0x100003f20 f40b0039 strb w20, [sp, 2]
0x100003f24 e8030079 strh w8, [sp]
0x100003f28 20008052 mov w0, 1
0x100003f2c 41008052 mov w1, 2
0x100003f30 62008052 mov w2, 3
0x100003f34 23008052 mov w3, 1
0x100003f38 44008052 mov w4, 2
0x100003f3c 65008052 mov w5, 3
0x100003f40 26008052 mov w6, 1
0x100003f44 47008052 mov w7, 2
0x100003f48 e6ffff97 bl sym._func
0x100003f4c 00008052 mov w0, 0
0x100003f50 fd7b44a9 ldp x29, x30, [sp, 0x40]
0x100003f54 f44f43a9 ldp x20, x19, [sp, 0x30]
0x100003f58 ff430191 add sp, sp, 0x50
0x100003f5c c0035fd6 ret
I am running a project using the ARM Embedded Tollchain on a stm32 microcontroller which uses the newLib.
I called assert(false) to test the assert output and ended in a Hard Fault Exception. I debugged into the assembly of assert(...) and found out that a subsequent call to _exit(1) jumps to a Address which is called _etext. Taking a look to the manpage of _etext shows that _etext is the address of the end of the .text section.
I am really confused. Normally I had supposed that _exit() is calling __exit() (which is defined as global symbol by the newLib) which I had implemented in a file named syscalls.c.
Why does _exit() jump to _etext?
Here are some cope snippets for a better understanding:
The subsequent call to _exit() by assert() taken from newLib 2.5:
_VOID
_DEFUN_VOID (abort)
{
#ifdef ABORT_MESSAGE
write (2, "Abort called\n", sizeof ("Abort called\n")-1);
#endif
while (1)
{
raise (SIGABRT);
_exit (1);
}
}
The disassembly of abort and assert. Take a special look to address 0808a10a where the jump to 80a5198 (_etext) is performed:
abort:
0808a100: push {r3, lr}
0808a102: movs r0, #6
0808a104: bl 0x808bfdc <raise>
0808a108: movs r0, #1
0808a10a: bl 0x80a51d8
0808a10e: nop
__assert_func:
0808a110: push {lr}
0808a112: ldr r4, [pc, #40] ; (0x808a13c <__assert_func+44>)
0808a114: ldr r6, [r4, #0]
0808a116: mov r5, r0
0808a118: sub sp, #20
0808a11a: mov r4, r3
0808a11c: ldr r0, [r6, #12]
0808a11e: cbz r2, 0x808a136 <__assert_func+38>
0808a120: ldr r3, [pc, #28] ; (0x808a140 <__assert_func+48>)
0808a122: str r2, [sp, #8]
0808a124: stmia.w sp, {r1, r3}
0808a128: mov r2, r4
0808a12a: mov r3, r5
0808a12c: ldr r1, [pc, #20] ; (0x808a144 <__assert_func+52>)
0808a12e: bl 0x808a5f4 <fiprintf>
0808a132: bl 0x808a100 <abort>
0808a136: ldr r3, [pc, #16] ; (0x808a148 <__assert_func+56>)
0808a138: mov r2, r3
0808a13a: b.n 0x808a122 <__assert_func+18>
0808a13c: str r0, [r3, #120] ; 0x78
0808a13e: movs r0, #0
0808a140: add r12, r11
0808a142: lsrs r2, r1, #32
0808a144: add r12, sp
0808a146: lsrs r2, r1, #32
0808a148: add r8, sp
0808a14a: lsrs r2, r1, #32
The lss-file which shows that 80a5198 is the address of _etext:
0808a0c0 <abort>:
808a0c0: b508 push {r3, lr}
808a0c2: 2006 movs r0, #6
808a0c4: f001 ff6a bl 808bf9c <raise>
808a0c8: 2001 movs r0, #1
808a0ca: f01b f865 bl 80a5198 <_etext>
808a0ce: bf00 nop
I am trying to set the text component of a label in the method prepareForSegue but the application is crashing when the method is executed, i've looked at other discussions but none of them have helped me, I am programming in swift in the latest version of xCode and building to an iPhone.
When I remove the line that sets the label's text to "Meal name", no crash occurs.
The breakpoint is on the line that sets the label's text.
If anyone can help me that would be great, thank you.
-- Edit --
prepareForSegue code of FirstViewController:
override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
let dest : SecondViewController = segue.destinationViewController as! SecondViewController
dest.mealNameLabel.text = "Meal Name"
}
Full stack trace: (-> is break)
libswiftCore.dylib`function signature specialization <Arg[0] = Exploded, Arg[1] = Exploded, Arg[2] = Dead, Arg[3] = Dead> of Swift._fatalErrorMessage (Swift.StaticString, Swift.StaticString, Swift.StaticString, Swift.UInt) -> ():
0x1001de55c <+0>: stp x29, x30, [sp, #-16]!
0x1001de560 <+4>: mov x29, sp
0x1001de564 <+8>: sub sp, sp, #16 ; =16
0x1001de568 <+12>: and w8, w2, #0x1
0x1001de56c <+16>: tbnz w8, #0, 0x1001de58c ; <+48>
0x1001de570 <+20>: tbnz x1, #63, 0x1001de5c8 ; <+108>
0x1001de574 <+24>: add x1, x0, x1
0x1001de578 <+28>: mov x2, x3
0x1001de57c <+32>: mov x3, x4
0x1001de580 <+36>: mov x4, x5
0x1001de584 <+40>: bl 0x1002265b0 ; function signature specialization <Arg[0] = Exploded, Arg[1] = Exploded> of Swift.(_fatalErrorMessage (Swift.StaticString, Swift.StaticString, Swift.StaticString, Swift.UInt) -> ()).(closure #2)
-> 0x1001de588 <+44>: brk #0x1
0x1001de58c <+48>: str xzr, [sp, #8]
0x1001de590 <+52>: cmp x0, w0, uxtw
0x1001de594 <+56>: b.ne 0x1001de6e0 ; <+388>
0x1001de598 <+60>: lsr w8, w0, #11
0x1001de59c <+64>: cmp w8, #26 ; =26
0x1001de5a0 <+68>: b.hi 0x1001de5ec ; <+144>
0x1001de5a4 <+72>: cmp w0, #128 ; =128
0x1001de5a8 <+76>: b.lo 0x1001de630 ; <+212>
0x1001de5ac <+80>: cmp w0, #2048 ; =2048
0x1001de5b0 <+84>: b.hs 0x1001de660 ; <+260>
0x1001de5b4 <+88>: movz x8, #0
0x1001de5b8 <+92>: movz x10, #0
0x1001de5bc <+96>: lsr w9, w0, #6
0x1001de5c0 <+100>: orr w9, w9, #0xffffffc0
0x1001de5c4 <+104>: b 0x1001de694 ; <+312>
0x1001de5c8 <+108>: adr x0, #723338 ; "fatal error"
0x1001de5cc <+112>: nop
0x1001de5d0 <+116>: adr x3, #723840 ; "UnsafeBufferPointer with negative count"
0x1001de5d4 <+120>: nop
0x1001de5d8 <+124>: movz w1, #0xb
0x1001de5dc <+128>: orr w2, wzr, #0x2
0x1001de5e0 <+132>: movz w4, #0x27
0x1001de5e4 <+136>: orr w5, wzr, #0x2
0x1001de5e8 <+140>: bl 0x1001de55c ; <+0>
0x1001de5ec <+144>: cmp w0, #14, lsl #12 ; =57344
0x1001de5f0 <+148>: b.lo 0x1001de63c ; <+224>
0x1001de5f4 <+152>: cmp w0, #272, lsl #12 ; =1114112
0x1001de5f8 <+156>: b.hs 0x1001de738 ; <+476>
0x1001de5fc <+160>: lsr w8, w0, #6
0x1001de600 <+164>: lsr w9, w0, #16
0x1001de604 <+168>: cbz w9, 0x1001de664 ; <+264>
0x1001de608 <+172>: lsr w9, w0, #18
0x1001de60c <+176>: orr w9, w9, #0xf0
0x1001de610 <+180>: cmp w9, w9, uxtb
0x1001de614 <+184>: b.ne 0x1001de6e0 ; <+388>
0x1001de618 <+188>: orr w10, wzr, #0xffffff80
0x1001de61c <+192>: bfxil w10, w0, #12, #6
0x1001de620 <+196>: and x12, x9, #0xff
0x1001de624 <+200>: str x12, [sp, #8]
0x1001de628 <+204>: orr w11, wzr, #0x1
0x1001de62c <+208>: b 0x1001de674 ; <+280>
0x1001de630 <+212>: movz x8, #0
0x1001de634 <+216>: movz x9, #0
0x1001de638 <+220>: b 0x1001de6d0 ; <+372>
0x1001de63c <+224>: adr x0, #723222 ; "fatal error"
0x1001de640 <+228>: nop
0x1001de644 <+232>: adr x3, #726652 ; "high- and low-surrogate code points are not valid Unicode scalar values"
0x1001de648 <+236>: nop
0x1001de64c <+240>: movz w1, #0xb
0x1001de650 <+244>: orr w2, wzr, #0x2
0x1001de654 <+248>: movz w4, #0x47
0x1001de658 <+252>: orr w5, wzr, #0x2
0x1001de65c <+256>: bl 0x1001de55c ; <+0>
0x1001de660 <+260>: lsr w8, w0, #6
0x1001de664 <+264>: lsr w9, w0, #12
0x1001de668 <+268>: movz x11, #0
0x1001de66c <+272>: movz x12, #0
0x1001de670 <+276>: orr w10, w9, #0xffffffe0
0x1001de674 <+280>: lsl x13, x11, #3
0x1001de678 <+284>: orr w9, wzr, #0xffffff80
0x1001de67c <+288>: bfxil w9, w8, #0, #6
0x1001de680 <+292>: and w8, w10, #0xff
0x1001de684 <+296>: lsl x8, x8, x13
0x1001de688 <+300>: orr x10, x8, x12
0x1001de68c <+304>: str x10, [sp, #8]
0x1001de690 <+308>: add x8, x11, #1 ; =1
0x1001de694 <+312>: orr w11, wzr, #0x8
0x1001de698 <+316>: umulh x11, x8, x11
0x1001de69c <+320>: cmp xzr, x11
0x1001de6a0 <+324>: b.ne 0x1001de6e0 ; <+388>
0x1001de6a4 <+328>: lsl x11, x8, #3
0x1001de6a8 <+332>: cmp x11, #63 ; =63
0x1001de6ac <+336>: b.hi 0x1001de714 ; <+440>
0x1001de6b0 <+340>: orr w12, wzr, #0x80
0x1001de6b4 <+344>: bfxil x12, x0, #0, #6
0x1001de6b8 <+348>: and w9, w9, #0xff
0x1001de6bc <+352>: lsl x9, x9, x11
0x1001de6c0 <+356>: orr x9, x9, x10
0x1001de6c4 <+360>: str x9, [sp, #8]
0x1001de6c8 <+364>: add x8, x8, #1 ; =1
0x1001de6cc <+368>: mov x0, x12
0x1001de6d0 <+372>: orr w10, wzr, #0x8
0x1001de6d4 <+376>: umulh x10, x8, x10
0x1001de6d8 <+380>: cmp xzr, x10
0x1001de6dc <+384>: b.eq 0x1001de6e4 ; <+392>
0x1001de6e0 <+388>: brk #0x1
0x1001de6e4 <+392>: lsl x10, x8, #3
0x1001de6e8 <+396>: cmp x10, #64 ; =64
0x1001de6ec <+400>: b.hs 0x1001de714 ; <+440>
0x1001de6f0 <+404>: and x11, x0, #0xff
0x1001de6f4 <+408>: lsl x10, x11, x10
0x1001de6f8 <+412>: orr x9, x10, x9
0x1001de6fc <+416>: str x9, [sp, #8]
0x1001de700 <+420>: add x9, sp, #8 ; =8
0x1001de704 <+424>: add x8, x8, x9
0x1001de708 <+428>: add x1, x8, #1 ; =1
0x1001de70c <+432>: add x0, sp, #8 ; =8
0x1001de710 <+436>: b 0x1001de578 ; <+28>
0x1001de714 <+440>: adr x0, #723006 ; "fatal error"
0x1001de718 <+444>: nop
0x1001de71c <+448>: adr x3, #723412 ; "shift amount is larger than type size in bits"
0x1001de720 <+452>: nop
0x1001de724 <+456>: movz w1, #0xb
0x1001de728 <+460>: orr w2, wzr, #0x2
0x1001de72c <+464>: movz w4, #0x2d
0x1001de730 <+468>: orr w5, wzr, #0x2
0x1001de734 <+472>: bl 0x1001de55c ; <+0>
0x1001de738 <+476>: adr x0, #722970 ; "fatal error"
0x1001de73c <+480>: nop
0x1001de740 <+484>: adr x3, #726480 ; "value is outside of Unicode codespace"
0x1001de744 <+488>: nop
0x1001de748 <+492>: movz w1, #0xb
0x1001de74c <+496>: orr w2, wzr, #0x2
0x1001de750 <+500>: movz w4, #0x25
0x1001de754 <+504>: orr w5, wzr, #0x2
0x1001de758 <+508>: bl 0x1001de55c ; <+0>
This is the code for the view controller that I am accessing with dest:
(Thanks to Emptyless)
//
// SecondViewController.swift
// FoodTracker
//
// Created by Michael Buerger on 7/4/16.
// Copyright © 2016 Michael Buerger. All rights reserved.
//
import UIKit
class SecondViewController: UIViewController {
// MARK: Properties
#IBOutlet weak var mealNameLabel: UILabel!
var mealName: String?
override func viewDidLoad() {
super.viewDidLoad()
if mealName != nil {
mealNameLabel.text = mealName
}
}
}
Most likely the problem is that you are accessing an IBOutlet that has not yet been initialized. If instead of setting the UITextLabel directly you create a variable that holds the text you might have more luck:
As property of SecondViewController:
var labelText : String?
In prepareForSegue() of FirstViewController:
des.labelText = "Your Text"
and in the viewDidLoad() of SeconViewController:
self.MeatNameLabel.text = labelText
I have a meteor + cordova app that I want to build for iOS. When running the app with Xcode, I sometimes get this blocking error :
libobjc.A.dylib`objc_msgSend:
0x334e1f60 <+0>: cbz r0, 0x334e1f9e ; <+62>
0x334e1f62 <+2>: ldr.w r9, [r0]
-> 0x334e1f66 <+6>: ldrh.w r12, [r9, #0xc]
0x334e1f6a <+10>: ldr.w r9, [r9, #0x8]
0x334e1f6e <+14>: and.w r12, r12, r1
0x334e1f72 <+18>: add.w r9, r9, r12, lsl #3
0x334e1f76 <+22>: ldr.w r12, [r9]
0x334e1f7a <+26>: teq.w r12, r1
0x334e1f7e <+30>: bne 0x334e1f86 ; <+38>
0x334e1f80 <+32>: ldr.w r12, [r9, #0x4]
0x334e1f84 <+36>: bx r12
0x334e1f86 <+38>: cmp.w r12, #0x1
0x334e1f8a <+42>: blo 0x334e1f98 ; <+56>
0x334e1f8c <+44>: it eq
0x334e1f8e <+46>: ldreq.w r9, [r9, #0x4]
0x334e1f92 <+50>: ldr r12, [r9, #8]!
0x334e1f96 <+54>: b 0x334e1f7a ; <+26>
0x334e1f98 <+56>: ldr.w r9, [r0]
0x334e1f9c <+60>: b 0x334e21e0 ; _objc_msgSend_uncached
0x334e1f9e <+62>: mov.w r1, #0x0
0x334e1fa2 <+66>: bx lr
0x334e1fa4 <+68>: nop
0x334e1fa6 <+70>: nop
0x334e1fa8 <+72>: nop
0x334e1faa <+74>: nop
0x334e1fac <+76>: nop
0x334e1fae <+78>: nop
0x334e1fb0 <+80>: nop
0x334e1fb2 <+82>: nop
0x334e1fb4 <+84>: nop
0x334e1fb6 <+86>: nop
0x334e1fb8 <+88>: nop
0x334e1fba <+90>: nop
0x334e1fbc <+92>: nop
0x334e1fbe <+94>: nop
On line 4 (where the -> arrow is), I get the message
Webthread (11): EXC_BAD_ACCESS (code=1, address=0xa000000c)
It happens every now and then, I can't seem to reproduce it. Can anybody tell me what this error means ?
Thanks !