GNU Binutils 2.47: RISC-V 확장과 디버깅 개선, s390 32비트 폐기 예고
GNU Binutils 2.47의 RISC-V 지원, objdump·readelf 개선, 링커 변화와 s390 32비트 호환성 영향을 정리했다.
컴파일러와 운영체제의 바닥을 받치는 GNU Binutils 2.47이 2026년 7월 26일 공개됐다. 어셈블러, 링커, objdump, readelf를 묶은 도구 모음인 만큼 애플리케이션 개발자가 직접 설치하지 않더라도 리눅스 배포판과 교차 컴파일 툴체인을 통해 영향을 받는다.
무엇이 바뀌었나
이번 릴리스는 RISC-V의 여러 표준 벡터·행렬 연산 확장을 추가했다. AArch64 디스어셈블러에는 정의되지 않은 명령과 연결된 심볼을 표시하는 -M annotate가, x86과 x86-64에는 즉시값과 관련된 심볼을 보여주는 -M annotate-immediates가 생겼다.
objdump와 readelf는 분리된 디버그 정보의 위치를 지정하는 --debug-dir 옵션을 지원한다. objdump --map-global-vars는 오브젝트 파일 속 전역 변수의 위치와 형식을 보여준다. BFD 링커의 -O 0은 병합 가능한 섹션을 합치지 않아 결과물 크기를 늘리는 대신 링크 시간을 줄일 수 있다.
링커에는 여러 오브젝트 파일을 인공 아카이브처럼 다루는 --start-lib와 --end-lib도 추가됐다. 심볼 인덱스가 없는 아카이브 지원은 XCOFF뿐 아니라 모든 형식에서 기본 활성화된다.
개발자에게 왜 중요한가
디버깅 도구의 심볼 주석 기능은 크래시 덤프나 펌웨어 역공학에서 숫자 주소가 어떤 심볼과 연결되는지 확인하는 시간을 줄인다. 별도 디버그 파일을 빌드 산출물과 분리해 보관하는 조직은 --debug-dir로 분석 절차를 단순화할 수 있다.
RISC-V 지원 확대는 새 명령 확장을 사용하는 실리콘과 컴파일러 백엔드가 같은 어셈블러 문법을 공유하도록 돕는다. 다만 Binutils가 명령을 인식한다고 해서 사용 중인 CPU가 해당 확장을 실행한다는 뜻은 아니다. 빌드 플래그와 실제 하드웨어 기능을 함께 맞춰야 한다.
기존 프로젝트 영향
가장 분명한 호환성 변화는 32비트 s390 대상의 폐기 예정 처리다. 기본 configure는 s390 32비트 대상을 오류로 거부하며, 임시로 --enable-obsolete를 사용해야 한다. 64비트 s390x는 계속 지원된다. Linux 6.19가 32비트 s390 호환 지원을 제거했고, Glibc 2.43과 GCC 16.1도 같은 대상을 폐기 예정으로 표시한 흐름과 맞닿아 있다.
또 하나의 주의점은 홀수 번호 릴리스인 2.47 소스 묶음에 GOLD 링커가 포함되지 않는다는 점이다. GOLD를 명시적으로 빌드하거나 배포하는 환경이라면 기존 패키징 절차가 실패할 수 있다. 기본 BFD 링커나 LLVM lld를 쓰는 프로젝트에는 직접 영향이 제한적이다.
적용 전 확인 사항
- 배포판 패키지를 기다릴지, GNU 서명과 SHA-256을 검증해 직접 빌드할지 결정한다.
- 교차 컴파일 대상의 CPU 확장과
-march설정을 실제 하드웨어 사양과 대조한다. ld -O 0은 링크 속도와 바이너리 크기의 교환이므로 대표 빌드에서 두 값을 모두 측정한다.- s390 32비트 또는 GOLD 의존성이 있는 CI 작업은 업그레이드 전에 별도 시험한다.
- 도구 버전이 바뀌면 재현 가능한 빌드의 해시가 달라질 수 있으므로 기준 산출물을 새로 기록한다.
