Вопросы по -march=

Если без -Wa,-march=generic64 — ошибки нет

Ассемблер же не будет одни инструкции на другие заменять. Как написал, так и будет. Если ты ему сказал, что будешь использовать только инструкции из набора generic64 (не знаю, что там), но при этом используешь что-то из расширений, максимум, что он сможет сделать — выдать ошибку.

но при этом используешь что-то из расширений

какие и где могут использоваться расширения? передаётся только -O2 -Wall и -Wa,-march=generic64
или всё-равно где-то используется что-то (где?) ?
в каком наборе инструкций находится этот xgetbv? надо передать какой-то -mno- ?

или это в корне неправильно передавать -Wa,-march= ? с gcc'шным -march=x86-64 == -Wa,-march=generic64 та же ошибка

или джисисишный -march=x86-64 и as'овский -march=generic64 — не одно и то же?
почему в gcc нет generic64, а в as нет x86-64 ? как правильно?

Видимо, собственно компилятор где-то генерирует эту инструкцию. Но сходу по коду GCC 11 не видно, чтобы он эту инструкцию сам вставлял, без прямой указки в коде.

что будет использоваться в качестве -march= для as, если вручную не указывать -Wa,-march=, а указать -march=x86-64 для gcc?

Попробуй запустить через strace:

strace -ff -o log gcc -march=x86-64 helloworld.c

В файлах log.* поищи запуск «as». На моей машине в параметрах кроме входного и выходного файлов я вижу только --64.

sysdeps/x86/cpu-features.c https://sebsauvage.net/paste/?47fc077c99bbff3d#KARnbR4I27J2Bl/HjmbZG 5wZ0AW3B...
строка 154:

asm ("xgetbv" : "=a" (xcrlow), "=d" (xcrhigh) : "c" (0));

у меня тоже тока --64 передал. helloworld с -Wa,-march=generic64 успешно собирается.
а зачем два -f для strace, или опечатка?

зачем два -f для strace

Это сокращение для --follow-forks --output-separately. Strace будет следить за потомками, но при этом ещё и будет складывать трассировку в отдельные файлы.

Если я задам -march=amdfam10, будет работать на вообще ВСЕХ процах AMD последующих поколений, или не на ВСЕХ (3DNow! и т.д.)?

Не факт. Лучше подстраховаться и посмотреть какие общие фичи у целевых архитектур, либо указать уровень микроархитектуры

https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

в райзенах выкинули позорные проприетарные вендорлочные амд инструкции

священная корпорация АМД даже выкинула совместимость с Интеловским изобретением - x86, именно поэтому их процессоры больше не являются x86-совместимыми

Ура!

OSXSAVE это что? xgetbv походу из такого набора инструкций.
выше ссылку дал на исходник из glibc, может, там баг? может, он вообще не должен эту 154 строку выполнять?

это что?

xsave, наверное.

выше ссылку дал на исходник из glibc, может, там баг? может, он вообще не должен эту 154 строку выполнять?

Почему?

не знаю. почему выводит ошибку? в /proc/cpuinfo нет никаких xsave.
есть строка bugs: fxsave_leak sysret_ss_attrs
что проверяет if (CPU_FEATURES_CPU_P (cpu_features, OSXSAVE)) ?

почему выводит ошибку?

Наверное, потому что авторы as решили, что инструкция xgetbv не входит в набор инструкций generic64.

что проверяет if (CPU_FEATURES_CPU_P (cpu_features, OSXSAVE)) ?

Кажется, это проверка включенности xsave.

CR4.OSXSAVE
XSAVE and Processor Extended States-Enable Bit (bit 18 of CR4) — When set, this flag: (1) indicates (via CPUID.01H:ECX.OSXSAVE[bit 27]) that the operating system supports the use of the XGETBV, XSAVE and XRSTOR instructions by general software; (2) enables the XSAVE and XRSTOR instructions to save and restore the x87 FPU state (including MMX registers), the SSE state (XMM registers and MXCSR), along with other processor extended states enabled in XCR0; (3) enables the processor to execute XGETBV and XSETBV instructions in order to read and write XCR0. See Section 2.6 and Chapter 13, “System Programming for Instruction Set Extensions and Processor Extended States”.

так где корень проблемы? OSXSAVE он разве входит в x86-64? в википедии по приведённой несколько выше ссылке указано что он входит в x86-64-v3. правда у меня сейчас gcc версии 10.3, а поддержка этих "под-уровней" вроде как с 11 версии, в CRUX новый не завезли, хотя, можно попробовать самому...
а amdfam10 входит в x86-64-v2? или это ещё x86-64?

даже когда я указываю -mno-xsave для gcc — та же ассемблерная ошибка

Бери /etc/portage.make.conf из stage3 от Funtoo для твоего камня. Какой именно stage3 брать у них же на сайте будет написано.

Этот вопрос лучше задавать где-нибудь в рассылке binutils, или где там живёт as. Шансов получить внятный ответ там намного больше.

За всё время в этой теме я толком не понял, что ты вообще пытаешься выяснить. Вот есть компилятор, который на выходе генерирует ассемблерный листинг. Есть ассемблер, который ассемблерный листинг переводит в объектные файлы. И есть фронтенд, который запускает препроцессор, компилятор и ассемблер. У компилятора и ассемблера разный набор флагов. Ассемблер вообще не в курсе, что значит «x86-64». У него в опциях есть только «generic64». Выходит, что у компилятора и ассемблера разные взгляды на мир. Наборы инструкций хоть и пересекаются, но не совпадают точно.

хочу выяснить, как правильно указывать -march= для as через CFLAGS="-Wa,-march=" для gcc. или узнать, например, что так делать нельзя... как правильно? т.е. получается некорректно указывать -Wa,-march для as если указан -march= для gcc?

Да ты вроде всё правильно делаешь. В инструкции к GCC (https://gcc.gnu.org/onlinedocs/gcc/Assembler-Options.html) написано, что опции ассемблеру передаются через -Wa,option.

то что через -Wa понятно. вопрос в том, как правильно указать этот ,-march=... не будет ли лишним его указывать, если и так указан CFLAGS="-march=x86-64"? т.е. если я всё-таки укажу, даже если это не требуется и итак прередаётся по дефолту от gcc к as

там просто ещё можно указывать -Wa,-march=generic64+sse+sse2+sse3+......... хочу подобрать правильные наборы инструкций. почему проверка на OSXSAVE выполнилась успешно?

получается некорректно указывать -Wa,-march для as если указан -march= для gcc?

Нет же. Когда ты указываешь -march= для GCC, ты ему разрешаешь генерировать определённые наборы инструкций. Я плохо понимаю, что произойдёт, если ты в сишных исходниках в asm блоках вставишь инструкцию, выходящую за список разрешённых. Возможно, компилятор в GCC пропустит её через себя без проверок. Далее, когда ты указываешь -Wa,-march= для ассемблера, ты ему указываешь чёткий набор инструкций, который он будет обрабатывать. Если он встречает инструкцию вне этого набора, это жёсткая ошибка.

С помощью -Wa,-march= ты можешь жёстко контролировать генерируемые инструкции. Гарантировать, что в бинарник не попадут инструкции, которые ты там не хотел бы видеть. Везде есть нюансы, но в общих чертах так.

почему проверка на OSXSAVE выполнилась успешно?

Потому что это просто проверка бита в регистре cr4. Этот регистр есть, кажется, с 80486. То есть можно считать, что он есть на всех актуальных процессорах.

т.е. он есть в x86-64? а почему в таблице в википедии OSXSAVE появляется только с x86-64-v3? не совсем понятно. пробовал кстати указывать generic64+sse+sse2+sse3+xsave — там компиляция ещё дальше шла, но потом тоже что-то было про то as не знает какой-то инструкции (не сохранил лог). т.е. всё-же ему нужно указывать +xsave и будет работать на x86-64?

Непонятно зачем указывать это для ассемблера, если компилятор и так выдаст нужный набор с ограничениями.

во-первых ради самообразования. во-вторых, я любли когда в моей системе всё сконфигурировано по максимуму (полный контроль), т.е. если даже какие-то опции назначаются по-умолчанию, часто всё-равно прописываю эти опции. на случай, если что-то пойдёт не так или разработчик решит в очередной версии изменить "дефолт"

я любли когда в моей системе всё сконфигурировано по максимуму (полный контроль)

Сразу после того как Вам удастся двигаться на юго-север с ненулевой скоростью.

вобщем, если OSXSAVE входит в x86, ладно, включил, если он нужен. далее ругается на инструкции xend, xbegin, xabort. накопал, что они входят в TSX, который только в интелах и то токо с 2013. в man as и man gcc нет таких ключей. как отключить?

TSX инструкции есть (были) в glibc, но они там в скомпилированном виде, а ассемблер вряд ли смотрит внутрь бинарников. Возможно, у тебя в коде используется TSX в каких-нибудь заголовках?

в man gcc нет таких ключей

-mrtm/-mno-rtm для _xbegin(), _xend(), _xabort()

Правда смысл всех действий по отключению не ясен, кому надо напишет просто

void xend() {
  asm volatile(".byte 0x0f; .byte 0x01; .byte 0xd5" ::: "memory");
}

Пацаны, я нопесал программу, а она не компилируется, подскажите какие флаги надо в асемблер передать, чтобы компилировалось:

int main() { asm("ya sosal zhopu negra"); }

$ gcc -march=amdfam10 programma.c 
/tmp/ccUOr5Ne.s: Assembler messages:
/tmp/ccUOr5Ne.s:4: Error: no such instruction: `ya sosal zhopu negra'

Почему CGG так плохо компилирует?

добавил -mno-rtm. потом выяснил что авторы glibc в Makefile принудительно добавляют -mrtm пропатчил. оказалось что там действительно есть функции xend()... для чего это? набор инструкций, если верить википедии есть только в ынтэлах. патчить? переходить на другую библиотеку C? musl? какие ещё есть альтернативы? давно задумывался о правильности выбора libc

для чего это?

В рантайме определяют модель CPU и набор фич, доступных для CPU через cpuid (https://ru.wikipedia.org/wiki/CPUID) Соответственно для AMD никакого RTM не включится и эти функи хоть и будут скомпилены, но никогда не запустятся.

musl?

Он больше для embedded и всяких контейнеров имеет смысл в целях экономии места. Раньше на роутерах для тех же целей uclibc использовался, но сейчас даже его форк uclibc-ng почти помер. Так-то и на desktop musl никто не запрещает использовать, но можно ряд проблем получить с каким-нибудь софтом, который собирают и тестируют только под glibc.

на случай, если что-то пойдёт не так или разработчик решит в очередной версии изменить «дефолт»

Фундаментально неправильный подход. Вы считаете Вы лучше разработчика конкретной софтинки знаете как её правильно собирать? Ню-ню. Классика жанра - «fast-math». Вы её конечно включили, «я надеюсь»? И оно возможно даже какое-то время будет работать, пока первый «nan» не случится…

в configure разных програм видел ключи --arch и --cpu. где посмотреть, какие аргументы они принимают? где посмотреть список всех расширений архитектуры x86-64, там всякие sse3, 3dnow? чтоб знать что отключать. в https://en.wikipedia.org/wiki/X86_instruction_listings всё? если я соберу свежий gcc и задам -march=x86-64-v2 компилятор будет по умолчанию меньше включать наборов инструкций, чем он у меня делает в версии 10.3 при -march=x86-64? т.е. меньше придётся ручками убирать? есть ли возможность ограничить набор инструкций только амдэшными, как ключ -mamd64 у as?

Скорее всего, всё нужное тебе перечислено в выводе gcc --target-help.

хочу собрать glibc-32 c -mx32, не с -m32, при сборке ошибка:

+ export libc_cv_slibdir=/lib32
+ libc_cv_slibdir=/lib32
+ CPPFLAGS=
+ CFLAGS='-O2 -march=i686   -pipe -Wall -fdiagnostics-color=auto -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -Wno-error=parentheses'
+ export 'CC=gcc -mx32'
+ CC='gcc -mx32'
+ export 'CXX=g++ -mx32'
+ CXX='g++ -mx32'
++ : --host=x86_64-pc-linux-gnux32
+ ../glibc-2.36/configure --prefix=/usr --libdir=/usr/lib32 --libexecdir=/usr/lib32 --enable-kernel=4.5 --enable-add-ons --enable-bind-now --enable-tunables --enable-static-pie --enable-multi-arch i686-pc-linux-gnu --enable-stack-protector=strong --enable-stack-protector=all --with-headers=/w/t/pkg/usr/include --disable-cet --disable-werror --disable-profile --without-gd --without-selinux
configure: WARNING: you should use --build, --host, --target
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for i686-pc-linux-gnu-gcc... gcc -mx32
checking for suffix of object files... configure: error: in `/w/t/src/build':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details

...
Configured with: ../gcc-10.4.0/configure --prefix=/usr --libexecdir=/us
r/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__c
xa_atexit --enable-clocale=gnu --enable-shared --disable-nls --with-x=n
o --with-system-zlib --enable-multilib --enable-default-pie --enable-de
fault-ssp --with-pkgversion=CRUX-x86_64-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.4.0 (CRUX-x86_64-multilib) 
configure:2643: $? = 0
configure:2632: gcc -mx32 -V >&5
gcc: error: unrecognized command-line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:2643: $? = 1
configure:2632: gcc -mx32 -qversion >&5
gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:2643: $? = 1
configure:2648: checking for suffix of object files
configure:2670: gcc -mx32 -c -O2 -march=i686   -pipe -Wall -fdiagnostics-color=auto -fprofile-correction -fstack-clash-protection -fstack-protector-strong -fstack-protector-all  -Wno-error=parentheses  conftest.c >&5
cc1: error: CPU you selected does not support x86-64 instruction set
configure:2674: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "glibc"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla/"
| #define PACKAGE_URL "https://www.gnu.org/software/glibc/"
| #define PKGVERSION "(GNU libc) "
| #define REPORT_BUGS_TO "<https://www.gnu.org/software/libc/bugs.html>"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2688: error: in `/w/t/src/build':
configure:2690: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details

Наверное, стоит трактовать x32 как отдельную архитектуру, с кросс-компиляцией и прочим.

походу, да. нашёл LFS multilib -> https://linuxfromscratch.org/~thomas/multilib/chapter05/glibc.html там gcc и glibc собираются 64, 32 и x32. а можно x32 либы кидать не в /libx32, а в /lib32 ? т.е. иметь в /lib32 тока x32 без 32?

а можно x32 либы кидать не в /libx32, а в /lib32?

Я разрешаю. Это плохая идея, но так как разгребать последствия не мне, я не против.

Это плохая идея

почему? в мультилиб обязательно должны присутствовать и x32 и 32?

чем отличается у as -march=generic32 и -march=i686 ?

чем отличается у as -march=generic32 и -march=i686 ?

отвечу сам себе: genrtic32 — это и i386 и i486 и i586 и i686, я прав?

32 это обычный 32-битный код: 32-битные регистры, 32-битные указатели, 4 гига адресуемой памяти. x32 это 64-битный код, но с особенностями: 32-битные указатели, 4 гига адресуемой памяти, но с доступом к регистрам, включая все 64 бита и регистры r8-r15. В 64-битный процесс нельзя загрузить 32-битные библиотеки, в x32-процесс нельзя загрузить ни 64-битные, ни 32-битные библиотеки. В 64-битный теоретически можно разместить код из x32 библиотек, но ожидания этого кода по работе с памятью отличаются от родного 64-битного кода, так что любая работа с памятью приведёт к багам. В принципе, какие-то очень короткие функции может и будут работать, если там ещё и отличий по соглашениям о вызовах достаточно совместимые. Не читал об этом ещё.

generic32

Его разве не убрали вообще? Гуглятся обсуждения об удалении 32-битного generic в рассылке gcc. Сообщениям там скоро уже десяток лет как будет.