2011-01-27 9 views
0

私は少数のファイルで構成される単純なアプリケーションを持っています。ファイルは apptest.c、apptest.h、apptest.Sです。ちょっと混乱しているのは、 apptest_AUTO.sが出場する部分です。誰でもその目的は何ですか? が実際にアセンブリの入力として使用される前にプリプロセッサで処理された後に、アセンブラコードの別のコピーが作成されていると思いますか?もう1つのMakefileの質問

CC=/bin/sparc-elf-gcc 
CPP=/bin/sparc-elf-cpp 
CIS_ASM=bin/sparc-elf-as 

all: apptest.exe 

apptest.exe: apptest.o 
$(CC) apptest.o -o apptest.exe 

apptest.o: apptest.c apptest.h apptest.S 
$(CC) $(SFLAGS) apptest.c -o apptest_AUTO.s 
$(CPP) apptest.S >> apptest_AUTO.s 
$(CIS_ASM) apptest_AUTO.s -o apptest.o 

答えて

1

誰かが、オブジェクトコードにコンパイルする前に、アセンブラソースを自動的に変更する機会を望んでいました。 SPARCではなく、典型的には古いアーキテクチャー(M680x0、Z8000)や古いCコンパイラー(1980年代、2010年代ではありません)を以前から行ってきました。

示されたシーケンスが与えられていると、有用なことは起こりそうにないようです。

1

これは奇妙なことですが、apptest.cのコンパイルによってアセンブラコードの出力の最後にapptest.Sの前処理されたバージョンを貼り付けています。最終結果は、apptest.cとapptest.Sの両方から構築された単一のオブジェクトファイルになります。

2つのオブジェクトファイルの名前の衝突を防ぐためのハックのように見えます。従来のアプローチは、

CC=/bin/sparc-elf-gcc 
CPP=/bin/sparc-elf-cpp 
CIS_ASM=bin/sparc-elf-as 

all: apptest.exe 

apptest.exe: apptest.o apptest.s.o 
    $(CC) $+ -o apptest.exe 

apptest.o: apptest.c apptest.h 
    $(CC) $(CFLAGS) apptest.c -o apptest.o 

apptest.s.o: apptest.s 
    $(CIS_ASM) apptest.s -o apptest.s.o 
のようなものになります。
関連する問題