pdb는 VS를 컴파일하고 링크할 때 생성되는 파일인 "프로그램 데이터베이스" 파일을 말합니다. DPB 파일은 주로 소스 파일 이름, 변수 이름, 함수 이름, FPO, 해당 줄 번호 등을 포함하여 프로그램을 디버깅할 때 VS에 필요한 기본 정보를 저장합니다. PDB 파일은 프로젝트 컴파일 시 생성되며, 해당 모듈과 함께 생성됩니다.
이 튜토리얼의 운영 환경: Windows 7 시스템, Dell G3 컴퓨터.
PDB(Program DataBase), 전체 이름은 "Program Database" 파일로, VS를 컴파일하고 링크할 때 생성되는 파일입니다. DPB 파일은 주로 소스 파일 이름, 변수 이름, 함수 이름, FPO(프레임 포인터), 해당 줄 번호 등을 포함하여 프로그램을 디버깅할 때 VS에 필요한 기본 정보를 저장합니다. 디버깅 정보가 저장되기 때문에 일반적으로 PDB 파일은 디버그 모드에서 생성됩니다.
PDB 파일에는 소스 파일 경로 관련 정보가 기록되어 있어 PDB 파일 로드 시 관련 디버깅 정보를 소스 코드와 일치시킬 수 있습니다. 이를 통해 디버깅 중에 함수 호출, 변수 값 및 기타 관련 정보를 실시간으로 시각적으로 볼 수 있습니다. 모듈에 기록된 PDB 파일은 절대 경로입니다. 따라서 모듈이 현재 컴퓨터에 로드되어 있는 한 디버거는 자연스럽게 모듈의 경로 정보를 기반으로 해당 PDB 파일을 찾아 로드합니다. 마찬가지로 PDB 파일에 기록된 소스 파일 경로도 절대 경로이므로 PDB 파일이 현재 컴퓨터에 로드되고 해당 모듈로 디버깅되면 기록된 소스 파일과 일치하고 시각적으로 볼 수 있습니다. 해당 정보.
PDB 파일은 언제 생성되나요?
PDB 파일은 프로젝트를 컴파일할 때 생성됩니다. 해당 모듈(exe 또는 dll)과 함께 생성됩니다. 우리는 일반적으로 PDB 파일의 중요성을 인식하지 못할 수 있습니다. 왜냐하면 로컬에서만 개발하면 언제든지 조정할 수 있기 때문입니다. 여기서는 Private Build와 Public Build1이라는 두 가지 개념을 소개하고 싶습니다. 프라이빗 빌드는 개발 머신에서의 컴파일을 의미하고, 퍼블릭 빌드는 컴파일을 담당하는 머신에서의 컴파일을 의미합니다.
위에서 말했듯이, 컴파일된 머신에서 디버깅에 필요한 모든 파일이 있어야 할 곳에 있기 때문에 일반적으로 Private Build에는 문제가 없습니다. 디버깅할 수 없는 문제는 대부분 Public Build의 경우에 발생합니다.
애플리케이션을 제품으로 게시하거나 판매해야 하는 경우 게시하는 버전의 PDB 파일과 소스 파일을 저장하는 데 특별한 주의를 기울여야 합니다. 참고: 게시된 PDB 파일을 저장할 수 있는 기회는 단 한 번뿐입니다. 파일을 분실하면 검색할 수 없습니다. 2 (이유는 아래 설명)
PDB가 왜 중요한가요?
동일한 소스 코드를 가져와서 PDB 파일을 만든 다음 디버깅에 사용하세요. 그렇게 생각하곤 했는데, 언젠가는...
직접적인 이유는 VS에서 생성된 바이너리 파일의 Header 부분에 해당 PDB의 GUID가 포함되어 있고, PDB에도 GUID 두 개가 추가되어 있기 때문입니다. 컴파일하는 동안. VS 디버거는 PDB를 로드할 때 두 GUID를 비교합니다. 일치하지 않으면 사용할 수 없습니다.
물론, 위의 이유는 단지 표면적인 현상일 뿐입니다. 근본적인 이유는 컴파일러에 의해 컴파일된 파일이 두 개의 동일한 코드와 다를 수 있다는 것입니다. 컴파일러는 컴파일할 때 코드를 최적화하고 동일한 코드에 여러 가지 최적화 방법이 있을 수 있으므로 당시의 특정 기계 환경을 기반으로 가장 빠른 생성 방법을 선택합니다. 따라서 생성되는 파일이 다를 수 있습니다! 따라서 생성된 파일조차 다르면 원본 PDB의 기호에 해당하는 주소는 의미가 없게 됩니다.
바이너리 파일 및 PDB의 GUID를 보는 방법은 무엇입니까?
VS와 함께 제공되는 DUMPBIN 도구를 사용하여 이진 파일에서 예상하는 PDB의 GUID를 확인하세요. 기본적인 사용법은 DUMPBIN /HEADER 파일입니다. 구체적인 사용법은 MSDN(http://msdn.microsoft.com/zh-cn/library/c1h23y6c(v=vs.80).aspx)을 참조하세요.
PDB의 GUID를 보려면 다음 도구를 사용하여 PDB를 직접 가져올 수 있습니다.
http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P
PDB 파일 검색 전략
먼저 테스트 결과 디버깅 중 Visual Studio의 모듈 직렬 포트에서 모듈의 기호 검색 전략을 확인할 수 있습니다. 스크린샷을 보면 다음과 같은 결과를 확인할 수 있습니다.
1. 파일이 실행되거나 로드되는 주소
2. PE 파일 헤더에 하드 코딩된 주소입니다. obj
2.5 심볼서버가 구성되어 있다면, 2단계 이후에 먼저 심볼서버의 캐시 디렉토리에서 검색을 하셔야 합니다. 찾을 수 없다면 심볼서버로 가서 검색해 보세요. 발견되면 캐시 디렉토리에 다운로드됩니다.
3. 세 번째 부분은 내 VS에 설정된 일부 기호 쿼리에 대한 디렉터리입니다. Reflector를 설치했기 때문에 이러한 디렉터리는 기본적으로 내 설정에 추가됩니다.
4. 윈도우 폴더.
여기서 흥미로운 현상은 VS의 검색 전략이 먼저 디렉터리에서 Symbolexeproject.pdb를 찾은 다음 exeproject.pdb, 마지막으로 project.pdb를 찾는다는 것입니다. 이 순서는 다소 놀랍습니다.
PDB 파일이 성능에 영향을 미치나요?
어떤 사람들은 PDB 파일 생성이 최종 애플리케이션의 성능에 일정한 영향을 미칠 것이라고 생각할 수 있으므로 릴리스 버전에서는 PDB 파일을 생성하면 안 된다고 생각합니다.
틀렸어! .NET 애플리케이션의 경우 PDB 파일 생성은 컴파일러 최적화에 영향을 주지 않으므로 애플리케이션 성능에는 전혀 영향을 미치지 않습니다. 생성된 어셈블리에 있는 하나의 DebuggableAttribute 특성에만 영향을 미칩니다. 관심 있는 분은 Do PDB Files Affect Performance?
관련 비디오 튜토리얼 권장 사항: "ASP.NET Tutorial"
을 읽어보세요.위 내용은 pdb는 어떤 파일인가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!