Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Debug symbols on macOS

Đang mở
  • Có gì không ổn?
#354 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
macos, python, shell
Lĩnh vực
build-system

Hướng nghiên cứu

Bắt đầu bằng cách xác định các lệnh build và link macOS trong build script, sau đó xem xét cách hoạt động của biên dịch riêng biệt, LTO và việc xử lý các debug symbol. Kiểm tra các tùy chọn linker được mô tả trong issue và bước dsymutil được đề xuất; được coi là hoàn tất khi executable macOS được phát hành có thông tin debug có thể sử dụng và bundle dSYM của nó có thể được đóng gói.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

The build script builds Python with debug symbols, but on macOS the debug symbols are not embeded in the executable, they stay in the object files if compilation and linking are done separately, so the shipped executable is missing debugging info. A separate call to dsymutil would be needed to package the debug symbols in a dSYM bundle that could be distributed with the package.

Also, since Python is built with link time optimization, a linker flag would have to be added the the link command.

Full explanation (from https://github.com/conda-forge/gdb-feedstock/pull/23/#issuecomment-643008755):

  • on macOS, the full debug info is never stored in the executable. It is either left in the object files, and the executable just keeps a record of the paths to the object files, or it is put into a "dSYM bundle".

  • when compiling and linking in a single step with the clang/clang++ drivers and the -g flag, i.e.

    clang -o app -g main.cpp Matrix.cpp Vector.cpp cholesky.cpp ...

    the driver automatically calls dsymutil at the end of the process to create this dSYM bundle. (this can be seen by adding -v to tell the driver to output all commands it issues.)

  • when compiling and linking in separate steps, which is usually the case with Make- or Automake- based build systems, the driver does not call dsymutil, so the debug info is left in the object files.

  • When compiling and linking in a single step with -flto, the driver calls the linker with the -object_path_lto flag and a path in $TMPDIR, eg. -object_path_lto /var/folders/lr/r6n2057j0dzd4gdb614fp0740000gp/T/cc-ac0bf8.o.

  • when compiling and linking in separate steps, the driver does not add this option to the linker call.

  • man ld reveals that if object_path_lto is not used, the linker deletes the temporary file used for link time optimization after the linking step is finished.

The last point means that the final executable keeps a reference to this deleted temporary file (I guess /tmp/lto.o is hardcoded in ld64's source code, I did not check that). So when the executable is loaded in GDB, the debugger tries to load the debugging symbols from the now deleted temporary file.

Adding -Wl,object_path_lto,lto.o to the linking command (in a Makefile for example) leaves the object file used for link time optimization (here lto.o) in the build directory, which allows to debug the executable. It also allows calling dsymutil manually to create the dSYM bundle.

References:

Of course having debug symbols distributed with a conda-forge package would have to be discussed on each package's feedstock. It would mean telling the build system of each package to add the flag -Wl,object_path_lto,lto.o, adding a call to dsymutil in build.sh, and copying the dSYM bundle to the recipe prefix.

Note: this issue is kind of orthogonal to other already opened issues (#73, #86, https://github.com/conda-forge/conda-forge.github.io/issues/1017), since building Python with debugging symbols is different from a "pydebug" build of Python

Ngôn ngữ chính
Shell
Star
47
Fork
115
Merge trung bình
2 ngày 4 giờ
Pull request đã merge (30 ngày)
18

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của conda-forge/python-feedstock

Tất cả issue của conda-forge/python-feedstock

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.