Ассемблер, используемый golang при сборке с cgo и без него

Допустим, у меня есть пакет golang, содержащий некоторый ассемблерный код:

 demopkg/
   source1.go
   source2.go
   asm_amd64.s

Если я попытаюсь собрать его с помощью go build, набор инструментов будет использовать go tool asm для сборки файлов *.s.

Но если я добавлю в смесь Cgo, поставив один import "C" в любой из исходников, go переключится на ассемблер gcc.

Я могу увидеть это, выполнив go build -n. Вызовы /usr/local/go/pkg/tool/linux_amd64/asm из первого случая заменяются вызовами gcc. Кроме того, он начинает жаловаться на неправильный синтаксис.

Задокументировано ли это поведение, чтобы я мог полагаться на него при обслуживании моего пакета? Могу ли я заставить go build использовать один точный ассемблер?


gcc go package assembly cgo
person bgeyts668    schedule 23.02.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Да, это есть в документации cgo.

Когда инструмент Go увидит, что один или несколько файлов Go используют специальный импорт «C», он будет искать в каталоге другие файлы, отличные от Go, и компилировать их как часть пакета Go. Любые файлы .c, .s или .S будут скомпилированы компилятором C. Любые файлы .cc, .cpp или .cxx будут скомпилированы компилятором C++. Любые файлы .h, .hh, .hpp или .hxx не будут компилироваться отдельно, но если эти заголовочные файлы будут изменены, файлы C и C++ будут перекомпилированы. Компиляторы C и C++ по умолчанию могут быть изменены переменными среды CC и CXX соответственно; эти переменные среды могут включать параметры командной строки.

person JimB    schedule 23.02.2016
comment
Ух ты, я видел эту страницу дюжину раз, но никогда не замечал часть о файлах .s. Я думаю, что единственный способ избежать этой функции - разделить пакеты... - person bgeyts668; 23.02.2016