Инструменты программирования

[Aether]

Доброго дня.

В виду регулярного затрагивания темы по х64 заинтересовался: кто и чем пользуется?

Стал изучать проблему более пристально, сперва обследовал NASM, как оказалось, современная версия позволяет собирать в объектный файл формата elf64. Но непонятно чем его линковать?

По компиляторам из-за нежелания использовать MSVC в доступном обозримом видится: MinGW-w64. Кто-нибудь им пользовался? Или есть ли лучшие аналоги, особенно, в плане легковесности?

Напомню, что комплект для Windows на настоящий момент у меня представляет из себя: NASM, ALINK и TCC.

Добавлено через 1 час, 10 минут и 8 секунд:
Установил для пробы: gcc (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 6.3.0

Проект с ключом -m32 собирается,
с ключом -m64 нет: sorry, unimplemented: 64-bit mode not compiled in #include <stdio.h>

Странно, библиотеки похоже тоже должны быть другими, хоть и комплект один?

[RXL]

Под win вообще не пишу. Компиляторы gcc или clang неплохо справляются с современными стандартами C/C++ и без проблем компилируют под amd64.

Необходимость в 64-битном коде на мой взгляд может быть в следующем:
1. ОС чисто 64 бита и никак иначе. Такое уже есть. Ну, тут и думать нечего.
2. Нужно использовать уже скомпиленные библиотеки под 64-битный код.
3. Есть нужда в выделении больших объемов памяти — более 2 ГБ на процесс. В противном случае будет экономичнее 32-битный код.
4. Тенденция. Если коду предстоит долгая служба, его стоит делать либо совместимым 32/64, либо сразу 64.

Установи 64-битный набор библиотек для рантайм и devel (там не только заголовки, но и линкующиеся части могут быть).

[Aether]

Установил MinGW из проекта TDM64: gcc (tdm64-1) 5.1.0. Собирает без проблем.

Про увеличение размера исполняемого файла я был в курсе, но не думал, что настолько - прирост в 163% получился. Зато по-современному.)

Мне теперь интересно: можно ли использовать этот комплект в качестве линковщика для NASM? И какие промежуточные форматы используются при компиляции в штатном х64 порядке?

[RXL]

Если nasm может производить объектные файлы, формата, поддерживаемого твоим линкером, то почему бы и нет.

$ nasm -v
NASM version 2.11.08 compiled on Jun 17 2015
$ nasm -hf
...
valid output formats for -f are (`*' denotes default):
  * bin       flat-form binary files (e.g. DOS .COM, .SYS)
    ith       Intel hex
    srec      Motorola S-records
    aout      Linux a.out object files
    aoutb     NetBSD/FreeBSD a.out object files
    coff      COFF (i386) object files (e.g. DJGPP for DOS)
    elf32     ELF32 (i386) object files (e.g. Linux)
    elf64     ELF64 (x86_64) object files (e.g. Linux)
    elfx32    ELFX32 (x86_64) object files (e.g. Linux)
    as86      Linux as86 (bin86 version 0.3) object files
    obj       MS-DOS 16-bit/32-bit OMF object files
    win32     Microsoft Win32 (i386) object files
    win64     Microsoft Win64 (x86-64) object files
    rdf       Relocatable Dynamic Object File Format v2.0
    ieee      IEEE-695 (LADsoft variant) object file format
    macho32   NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (i386) object files
    macho64   NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (x86_64) object files
    dbg       Trace of all info passed to output stage
    elf       ELF (short name for ELF32)
    macho     MACHO (short name for MACHO32)
    win       WIN (short name for WIN32)

[Aether]

Ну вот, как можно видеть есть формат: elf64, а есть win64. Для комбинацией с tcc я применял elf (elf32). Кстати, применение этих форматов не прозрачно, каждый требует определённых правил при написании asm кода.

Мне интересна последовательность в комплекте:
gcc преобразует (source.c + source.h) -> source.asm
as преобразует source.asm -> source.o
ld преобразует source.o -> source.exe

Таким образом, как я понимаю, соединять nasm и gcc нужно на этапе ld.
Соответственно:

GNU ld (GNU Binutils) 2.25

Выходные цели:

ld: supported targets: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64
elf64-l1om elf64-k1om pe-i386 pei-i386 elf32-i386 elf64-little elf64-big elf32-little
elf32-big plugin srec symbolsrec verilog tekhex binary ihex

Как понимаю моё: pe-x86-64? (pei-x86-64?) Но могу ошибиться. И на вход ему можно что угодно или что-то конкретно?

[RXL]

Мне интересна последовательность в комплекте:
gcc преобразует (source.c + source.h) -> source.asm
as преобразует source.asm -> source.o
ld преобразует source.o -> source.exe

Ассемблер тут не используется, если не указать явно.

Таким образом, как я понимаю, соединять nasm и gcc нужно на этапе ld.

А где ж еще...

Используй дефолтный формат. Не ломай голову там, где это можно не делать.

[Aether]

gcc -c -m64 -std=c99 source.c -o source.o
objdump -a source.o

source.o file format pe-x86-64

gcc -m64 -std=c99 source.c -o source.exe
objdump -a source.exe

source.exe file format pei-x86-64

Получается, что выходным должен быть pei-x86-64, а входным пока под вопросом.

Добавлено через 8 минут и 49 секунд:
И ещё вот какая тема: Windows при линковке должен получить информацию о том: консольное приложение или оконное, в общем, тоже есть ещё что почитать.

Используй дефолтный формат. Не ломай голову там, где это можно не делать.

Так и делаю, но тема про х64 уже всплывает не первый раз. Надо будет попробовать, к тому же посмотрел: в блоке РОН добавилось ещё 8 регистров, которые из х86 не доступны - R8 ... R15.