저는 Autotools/Automake/Autoconf를 사용하고 있으며리디렉션을 사용할 수 없습니다.왜냐하면 autotools로 생성된 make 파일에서 명령어별로 적용해야 하기 때문입니다.
각각과 관련된 컴파일러 및/또는 어셈블러 목록을 생성하고 저장하기 위한 규정을 사용하여 자동화된 도구를 사용하여 make 파일을 생성할 수 있는 방법이 필요합니다.개인의소스코드는 패키지에 있습니다.
나의 첫 번째 시도는 CCFLAGS에 "-Wa,-acdhln -g"를 추가하는 것이었습니다. 이는 복합 c/어셈블러 목록을 생성하지만터미널로 갔다,파일을 입력하지 마세요.. make 출력을 캡처하면(리디렉션 사용) 빌드 명령이 곳곳에 흩어져 있는 47개의 다른 목록을 얻게 됩니다.
내가 바라는 것은 GCC 문서를 낙관적으로 읽는 것입니다.전체 옵션 - GNU 컴파일러 컬렉션 사용,
-o file
출력을 file file에 배치합니다. 이는 실행 파일, 개체 파일, 어셈블러 파일 또는 전처리된 C 코드 등 생성된 모든 유형의 출력에 적용됩니다.-o를 지정하지 않으면 기본적으로 실행 파일은 a.out에, source.suffix의 대상 파일은 source.o에, 해당 어셈블러 파일은 source.s에, 미리 컴파일된 헤더 파일은 소스 .suffix.gch에 배치되고 모든 전처리된 C 소스 코드는 표준 출력에 표시됩니다.
GCC 명령줄의 "-o {file}.o"를 기반으로 {file}.o 및 {file}.s 파일을 표시하는 데 사용됩니다.
무슨 일이 일어나는지는 어셈블리 목록이 분명히 표준 출력으로 전송된다는 것입니다.
2016년 10월 23일을 추가하도록 수정되었습니다. 이제 문서에서는 컴파일러 출력 파일이 어셈블러에 입력으로 전달되고 어셈블러 출력 파일이 링커에 입력으로 전달되는 것과 같은 내용에 대해 이야기하고 있다는 것을 깨달았습니다. 캡처하려는 어셈블러 목록 파일도 마찬가지입니다.
이는 -save-temps 옵션을 사용하는 경우에도 적용됩니다. 이는 어셈블러 목록 파일이 아닌 링커 입력 파일인 어셈블러의 출력만 저장합니다.
문서에 대한 또 다른 해석은 각 출력 파일이 -o 피연산자에 지정된 단일 파일에 배치되거나 함께 혼합되거나 마지막으로 생성된 파일이 이전에 생성된 파일을 덮어쓰는 것을 의미할 수 있습니다. (예를 들어 컴파일러 채널의 출력은 어셈블리 채널의 출력을 재정의하는 어셈블러 채널의 출력을 재정의합니다.)
이는 비생산적인 것처럼 보이므로 GCC(최상위 실행자)가 해당 파일 이름을 조정할 만큼 똑똑할 수도 있다고 가정합니다. 다른 채널. 이것은 사실이 아닌 것 같습니다."-o"에서 파일 이름을 생략하는 것은 대상 파일의 이름이 항상 "{source}.o" 대신 "a.out"이라는 점을 제외하고는 정확히 우리가 원하는 것 같습니다. 소스 출력 이름 상수가 선택된 이유는 이해가 되지 않지만, 각 GCC 호출 후 이름 바꾸기 단계에서 "a.out"이 "{source}.o"로 변경될 수 있습니다.
찾다GNU 어셈블러 문서-o에 대한 명령이 적고 출력 목록을 처리하기 위한 옵션이 없습니다. 어셈블러 버전 tigcc는 이 목록을 기록하고 표준 출력으로 내보냅니다.
Unix용 GNU와 GNU Build Standard 개정판이 이 문제를 해결하지 않습니까?
(제가 미친 건가요, 아니면 그냥 유닉스라는 비현실적인 세상에 살고 있는 건가요???)
이제 Make는 어셈블리 단계를 실행할 때 표준 출력이 다음 위치에 배치되어야 한다고 GCC에 알려야 하는 것처럼 보입니다.[이메일 보호됨]문서. GCC 옵션이 작동하는 방식(그리고 사양 파일을 빠르게 살펴보는 방식)을 고려할 때 이것이 가능하다고 의심됩니다. 아마도 Automake(또는 libtools?)는 어셈블리 출력을 캡처할 수 있도록 개별 단계를 분리하여 다단계 컴파일 작업을 생성할 수 있습니다.
하지만,make 파일은 autotools에 의해 생성되므로 방법이 필요합니다.autotools에게 make 파일을 생성하라고 지시하세요그러면 어셈블리 출력 파일이 생성/캡처됩니다. 이 작업을 수행하려면 일부 autoconf/automake 규칙 및/또는 매크로를 다시 작성해야 하는 것 같습니다.
마지막으로, 저는 다른 사람들이 자동화 도구를 사용하여 생성하고 패키징하여 나에게 다운로드한 패키지를 사용하고 있습니다. 나는 자동화된 도구 패키징을 수행하지도 않고 거대한 *.ac 파일을 생성하지도 않으며, 피할 수만 있다면 해킹하고 싶지도 않습니다.
패키지 문제를 시도하고 디버깅하려면 어셈블리와 링크 맵이 필요합니다.
답변1
나는 마침내 분해하여 캡처된 터미널 출력을 분석하고 목록 파일을 추출하는 실제 프로그램을 작성했습니다. 내 특정 시스템/빌드 구성/패키지에 작동하지만 예제로만 제공할 수 있습니다. 확실히 사용하기 쉬운 도구는 아닙니다.
죄송합니다. 이는 자동 도구의 단점을 극복하기 위한 일반적인 답변이 아닙니다.