Gnu AS似乎沒有預處理#defines，但是GCC確實有

我有一個可能大量的常量，這些常量被越來越多的源文件使用。我需要能夠發揮它的價值，所以它很方便在一個地方定義。Gnu AS似乎沒有預處理#defines，但是GCC確實有

的我的情況的一個例子如下：

頭文件其中I定義變量，rmode_loc.h：

#define __ASSEMBLER__ 

#define BSEQ_HI 0xF000 
#define BSEQ_LO 0x0000

從一些代碼，他們（應）中使用的摘錄，MYPROG .S：

.code16 

/* Include constants */ 
#include "rmode_loc.h" 

_start: 

    ... 

    push $BSEQ_HI 

    ... 

    mov $BSEQ_LO, %bx

然而，在試圖編譯鏈接器將報告以下錯誤：

myprog.o: In function `_start': 
(.text+0x1b): undefined reference to `BSEQ_HI' 
myprog.o: In function `_start': 
(.text+0x1f): undefined reference to `BSEQ_LO'

很明顯正在嘗試鏈接這些「符號」 - 因此我得出結論，預處理器並未將符號替換爲rmode_loc.h指示的值。

我在另一個SO帖子（無法找到鏈接）上看到，如果源文件的擴展名爲.s，則不會發生預處理，並且還提供了定義__ASSEMBLER__的建議 - 但是，在這裏似乎沒有問題，因爲所有的信息源都有.S的擴展名，我在標題中添加了#define __ASSEMBLY__。

但是，當使用GCC作爲編譯的前端時，即gcc myprog.S -o myprog，BSEQ標籤被正確替換，並且編譯所有內容。

我的問題是，當使用as而不是gcc產生這些結果，以及是否有任何顯著的技術的不同使用gcc當編譯彙編代碼，而不是as有什麼區別在預處理是那裏？

來源

2016-02-29 Maxim Blinov

'gcc'管源通過c預處理器，如果擴展名是'.S'，就像你注意到的那樣。然後它只是調用'as'，所以沒有額外的差異。你可以使用'gcc -v'來看看它在做什麼。 – Jester

GNU as本身從來沒有進程#define指令。

的gcc命令的一個特點是，給定在.S結尾的文件名時，它運行在其上的C預處理cpp（其處理#define和#include等等），然後運行對所得到的輸出as。但是，如果給出的文件名以.s結尾，則它僅運行as。

如果你想使用C預處理指令，您可以命名您的文件.S和使用gcc命令，或者爲它們命名任何你想要的和手動兩者都做遍：

cpp foo.s |as -o foo.o -

來源

2016-02-29 22:17:33

Gnu AS似乎沒有預處理#defines，但是GCC確實有

回答

相關問題