여러분의 버그 보고는 ld를 신뢰있게 만드는 데 중요한 역할을 한다.
버그를 보고하는 것은 여러분의 문제에 대한 솔루션을 제공함으로써 여러분을
도울 수 있거나 그렇지 않을 수 있다. 그러나 어떤 경우에도 버그 보고의
주요 기능은 ld의 차기 버전이 좀 더 좋게 되는 것을 도운다. 버그
보고들은 ld의 유지보수(maintenance)에 대한 공헌이다.
버그 보고가 그 목적을 달성하도록 여러분은 반드시 버그를 교정할 수 있는 정보를 포함해야 한다.
버그를 발견한것인지 아닌지 확실하지 않을 때 다음 가이드라인들을 보자:
ld의
버그이다. 신뢰할 수 있는 링커들은 절대로 죽지 않는다.
ld가 유효한 입력에 대해서 에러 메시지를 출력하면 이것은 버그이다.
ld가 유효하지 않는 입력에 대해서 에러 메시지를 출력하지 않으면
이것은 버그일 수 있다. 일반적인 경우 링커는 오브젝트 파일들이 정확한가
아닌가를 검증할 수 없다.
ld의 개선 제안은 어떤
경우라도 환영이다.
많은 회사들과 개인들이 GNU 제품들에 대한 지원을 제공하고 있다. 지원
조직으로부터 ld를 얻었다면 우리는 그 조직과 먼저 접촉하라고
권하고 싶다.
GNU Emacs 배포판에 있는 `etc/SERVICE'파일에서 많은 지원 회사들과 개인들에 대한 접촉 정보를 찾을 수 있다.
임의의 이벤트에서 우리는 ld에 대한 버그 보고들을
`bug-gnu-utils@gnu.org'에게 보내주기를 권고하는 바이다.
버그를 보고하는 기본 원리는 다음과 같다:report all the facts. 어떤 사실을 말할 것인가 말하지 말아야 할 것인가 확실치 않다면 말하도록 하자.
종종 사람들은 그들이 그 문제의 원인을 안다고 생각하기 때문에 그리고 어떤 상세한 내용들이 문제가 전혀 없을것이라고 가정하기 때문에, 사실들을 생략한다. 그래서 여러분은 예제에서 사용한 어떤 심벌의 이름이 의미가 없다고 가정할 수 있을 것이다. 글쎄 그렇지 않을 것지지만 어떤 것은 확실치 않을 수 있다. 버그는 아마 그 이름이 메모리에 저장된 위치에서 가져오게 되는 길잃은(stray) 메모리 참조일 것이다; 이름이 다르면 그 위치의 내용물들은 버그에도 불구하고 정확한 것을 하도록 링커를 속일 것이다. 이것을 안전하게 갖고 놀고 완전하고 구체적인 예제를 제공하자. 이것이 여러분이 할 수 있는 가장 쉬운 일이고 가장 도움을 주는 일이다.
버그 보고의 목적은 우리가 그 버그가 새로운 것이라면 그것을 교정할 수 있도록 하는 것이라는 것을 기억하자. 그러므로 언제나 버그가 이전에 보고된 것이 아닌 것이라는 가정하에 버그 보고를 작성하자.
간혹 사람들은 몇가지 간략한(sketch) 사실들을 주고서 다음과 같이 묻는다, "이것이 벨을 울립니까?" 이런 버그 리포트들은 쓸모가 없고 우리는 버그를 적절하게 보고하도록 송신자를 잔소리하는 것을 제외하고 모든 사람들에게 그들에게 대답하지 말도록 요구한다.
버그를 교정할 수 있도록 하기 위해 여러분은 모든 다음의 것들을 포함해야 한다:
ld 버전. ld는 `--version' 매개변수를 주면 자신의
버전을 보여줄 것이다.
이것이 없으면 우리는 ld의 현재 버전에서 버그를 찾으면서 다른
포인트가 있는가 없는가를 알지 못할 것이다.
ld 소스에 적용했을 수도 있는 임의의 패치들. BFD
라이브러리에 적용된 임의의 패치들을 포함.
ld를 컴파일하는 데 사용한 컴파일러(그리고 그것의 버전)---예.
"gcc-2.7".
gas를 통해서 어셈블되거나 gcc를 사용해서
컴파일된다면 오브젝트 파일들이 아니라 소스 파일들을 보내도 좋다. 이런
경우 gas나 gcc의 어떤 버전이 그 오브젝트 파일들을 생성하는
데 사용되었는지 정확하게 말해주어야 한다. 또한 gas나 gcc가
어떻게 설정되었는지 말해주어야 한다.
ld가 치명적인 에러를 얻는 것이라면 우리는 분명 그것을
주목할 것이다. 그러나 그 버그가 부정확한 출력이라면 우리는 그것이 아주
틀린 것이 아니라면 주목하지 않을 것이다. 여러분은 또한 실수를 저지를
기회를 우리에게 제공해서는 안될 것이다.
여러분이 경험한 문제가 치명적인 것이라면 여러분은 그것을 명시적으로
얘기해야 할 것이다. ld의 여러분의 코드가 동기(synch)가 맞지
않는다든가 아니면 여러분의 시스템에서 C 라이브러리 상 버그를 만났다든가
하는 식의, 이상한 어떤 것이 일어났다고 가정하자. (이것이 일어났었던
것이다!) 여러분의 코드는 충돌할 것이지만 우리의 것은 그렇지 않을 수
있다. 어떤 충돌을 예상하고 우리에게 말하고 우리는 그런 충돌이 일어나지
않는다면 우리는 그 버그가 우리에게 일어나지 않는 것이라고 알것이다. 어떤
충돌이 일어날 것이라고 우리에게 말하지 않는다면 우리는 우리의 관찰로부터
어떤 결론도 도출하지 못할 것이다.
ld 소스에 대한 변경을 제안하고자 한다면 내용물 diff를 보내주기
바란다. diff 프로그램에 `-u', `-c', 또는 `-p'
옵션을 주어 만든 것을 보내주기 바란다. 항상 구버전에서 신버전으로
diff해서 보내주기 바란다. ld 소스에서 어떤 것을 논의하고자 한다면
그것을 라인번호가 아닌 내용물로 참조해 주기 바란다.
우리의 개발 소스들에 대한 라인 번호들은 여러분의 소스들과 일치하지 않을
것이다. 여러분의 라인 번호들은 우리에게 어떤 유용한 정보도 전달하지 않을
것이다
다음은 필수는 아닌 몇가지 것들이다:
ld만큼 복잡한 프로그램으로 코드내 어떤 경로를 따라가는
프로그램을 만들어주는 예제를 생성하는 것은 아주 어렵다. 예제를 보내주지
않는다면 우리는 그런 것을 하나 생성할 수 없을 것이고 그래서 그 버그가
교정된 것인지 아닌지를 검증할 수 없을 것이다.
여러분이 교정하고자 노력하고 있는 버그가 무엇인지 우리가 이해할 수
없다면, 또는 왜 여러분의 패치가 개선점이 되는 것인지 우리가 이해할 수
없다면 우리는 그것을 인스톨하지 않을 것이다. 검사 케이스가 우리가
이해하는 데 도움을 줄 것이다.
Go to the first, previous, next, last section, table of contents.