2016-02-23 4 views
0

Скажем, у меня есть golang пакет, который содержит код сборки:Ассемблер используется golang при строительстве и без ОЦП

demopkg/ 
    source1.go 
    source2.go 
    asm_amd64.s 

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

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

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

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

ответ

2

Да, это в cgo documentation

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

+0

Ой, вау, я видел эту страницу дюжину раз, но я никогда не замечал часть файлов .s. Я думаю, единственный способ избежать этой функции - разделить пакеты ... – bgeyts668