Linux не распознавать MacBook Pro в режиме целевого диска, подключенного к Thunderbolt
Давайте декомпилируем, чтобы посмотреть, что с этим делает GCC 4.8
Без expect
#include "stdio.h"
#include "time.h"
int main() {
/* Use time to prevent it from being optimized away. */
int i = !time(NULL);
if (i)
printf("%d\n", i);
puts("a");
return 0;
}
Компиляция и декомпиляция в GCC 4.8.2 x86_64 Linux:
gcc -c -O3 -std=gnu11 main.c
objdump -dr main.o
Выход:
0000000000000000 :
0: 48 83 ec 08 sub $0x8,%rsp
4: 31 ff xor %edi,%edi
6: e8 00 00 00 00 callq b
7: R_X86_64_PC32 time-0x4
b: 48 85 c0 test %rax,%rax
e: 75 14 jne 24
10: ba 01 00 00 00 mov $0x1,%edx
15: be 00 00 00 00 mov $0x0,%esi
16: R_X86_64_32 .rodata.str1.1
1a: bf 01 00 00 00 mov $0x1,%edi
1f: e8 00 00 00 00 callq 24
20: R_X86_64_PC32 __printf_chk-0x4
24: bf 00 00 00 00 mov $0x0,%edi
25: R_X86_64_32 .rodata.str1.1+0x4
29: e8 00 00 00 00 callq 2e
2a: R_X86_64_PC32 puts-0x4
2e: 31 c0 xor %eax,%eax
30: 48 83 c4 08 add $0x8,%rsp
34: c3 retq
Порядок инструкций в памяти не изменился: сначала printf, затем puts и retq return.
С ожиданием
Теперь замените if (i) на:
if (__builtin_expect(i, 0))
и мы получим:
0000000000000000 :
0: 48 83 ec 08 sub $0x8,%rsp
4: 31 ff xor %edi,%edi
6: e8 00 00 00 00 callq b
7: R_X86_64_PC32 time-0x4
b: 48 85 c0 test %rax,%rax
e: 74 11 je 21
10: bf 00 00 00 00 mov $0x0,%edi
11: R_X86_64_32 .rodata.str1.1+0x4
15: e8 00 00 00 00 callq 1a
16: R_X86_64_PC32 puts-0x4
1a: 31 c0 xor %eax,%eax
1c: 48 83 c4 08 add $0x8,%rsp
20: c3 retq
21: ba 01 00 00 00 mov $0x1,%edx
26: be 00 00 00 00 mov $0x0,%esi
27: R_X86_64_32 .rodata.str1.1
2b: bf 01 00 00 00 mov $0x1,%edi
30: e8 00 00 00 00 callq 35
31: R_X86_64_PC32 __printf_chk-0x4
35: eb d9 jmp 10
printf (скомпилированный в __printf_chk) был перемещен в самый конец функции, после puts и возврата, чтобы улучшить предсказание ветвлений, как упоминалось в других ответах.
Так что это в основном то же самое, что:
int i = !time(NULL);
if (i)
goto printf;
puts:
puts("a");
return 0;
printf:
printf("%d\n", i);
goto puts;
Эта оптимизация не была сделана с -O0.
Но удачи в написании примера, который работает быстрее с __builtin_expect, чем без него, процессоры действительно умны в наши дни. Мои наивные попытки здесь.
C++20 [[вероятно]] и [[маловероятно]]
C++20 стандартизировал эти встроенные модули C++: https://stackoverflow.com/questions/51797959/how-to-use-c20s-likely-unlikely-attribute-in-if-else-statement Они, вероятно (каламбур!), будут делать то же самое.
1
jaltair9
08.07.2018, 06:49
Ссылка
1 ответ
Возможно, у вас нет способа распознать его как внешний диск.
Начиная с High Sierra, Apple использует файловую систему Apple (APFS ), для которой еще нет драйверов Linux.
Apple File System (APFS) is a proprietary file system for macOS High Sierra and later, iOS 10.3 and later, tvOS 10.2 and later,[6] and watchOS 3.2 and later,[7] developed and deployed by Apple Inc.[8][9] It aims to fix core problems of HFS+ (also called Mac OS Extended), APFS's predecessor on these operating systems. Apple File System is optimized for flash and solid-state drive storage.
Возможное решение — создание промежуточного раздела FAT для обмена данными. Это может сработать. В противном случае вам понадобится другой Mac как минимум с High Sierra для доступа к этим данным.
Thunderbolt также не очень хорошо поддерживается в Linux.
1
Rui F Ribeiro
27.01.2020, 23:43
Ссылка