Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Debug symbols on macOS #354

Open
phil-blain opened this issue Jun 12, 2020 · 0 comments
Open

Debug symbols on macOS #354

phil-blain opened this issue Jun 12, 2020 · 0 comments

Comments

@phil-blain
Copy link

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 conda-forge/gdb-feedstock#23):

  • 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, conda-forge/conda-forge.github.io#1017), since building Python with debugging symbols is different from a "pydebug" build of Python
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 14, 2020
@phil-blain
enable macOS build
5b09c00 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably due to system security settings that need tweaking (I'm
suspecting a graphical authentification popup since that's what I
witnessed during local testing).

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
@phil-blain phil-blain mentioned this issue Jun 14, 2020
Merged
16 tasks
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 14, 2020
@phil-blain
enable macOS build
5c0894e 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably due to system security settings that need tweaking (I'm
suspecting a graphical authentification popup since that's what I
witnessed during local testing).

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 14, 2020
@phil-blain
enable macOS build
6067439 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably due to system security settings that need tweaking (I'm
suspecting a graphical authentification popup since that's what I
witnessed during local testing).

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 14, 2020
@phil-blain
enable macOS build
964ea0f 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably due to system security settings that need tweaking (I'm
suspecting a graphical authentification popup since that's what I
witnessed during local testing).

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 27, 2020
@phil-blain
enable macOS build
bf9b5f1 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably due to system security settings that need tweaking (I'm
suspecting a graphical authentification popup since that's what I
witnessed during local testing).

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 27, 2020
@phil-blain
enable macOS build
55c445d 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably a manifestation of an intermittent GDB bug [6].
We use the patch provided in the bug report to mitigate the effects
of that bug.

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
[6]: https://sourceware.org/bugzilla/show_bug.cgi?id=24069
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 27, 2020
@phil-blain
enable macOS build
9f10550 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.
We also re-introduce the Python test on Linux, which was deleted in
conda-forge#27.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably a manifestation of an intermittent GDB bug [6].
We use the patch provided in the bug report to mitigate the effects
of that bug.

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
[6]: https://sourceware.org/bugzilla/show_bug.cgi?id=24069
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 27, 2020
@phil-blain
enable macOS build
dc6c636 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably a manifestation of an intermittent GDB bug [6].
We use the patch provided in the bug report to mitigate the effects
of that bug.

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
[6]: https://sourceware.org/bugzilla/show_bug.cgi?id=24069
phil-blain added a commit to phil-blain/gdb-feedstock that referenced this issue Jun 29, 2020
@phil-blain
enable macOS build
b8e1f1f 
Add support for building GDB on macOS.

On macOS, debuggers need to be codesigned with a codesigning certificate
located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this
certificate. It is taken from the LLDB repository [1] and only slightly
modified to use "gdb_codesign" as the certificate name. Using a script
seems more robust than the manual method mentioned in the GDB wiki [2].
This script requires 'sudo', so it is run automatically on the CI but
not in a user installation. It is copied to the installation prefix
so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls
'macos-setup-codesign.sh' and then signs the GDB executable using the
just created certificate.

A post-link script runs the
`recipe/macos-codesign/macos-codesign-gdb.sh` is passwordless sudo is
available (in the CI), and if it's not, it writes to
$PREFIX/.messages.txt such that users are notified that they need to
sign GDB in order to use it, using the provided script.

An activate script is also added to make sure that GDB is correctly
codesigned upon environment activation. If it's not codesigned, users
are instructed to run the provided script.

Since the Python executable from the conda-forge python package does not
include debugging symbols on macOS (see [3],[4]), we skip the test for
the GDB "libpython" integration and add a simple "Hello World" C
program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge Travis macOS
image use macOS 10.13 ('xcode9.4') [5]. When tested under Azure and
Travis under macOS 10.14 and 10.15, the build
phase succeeds but when running the executable in GDB, GDB hangs.
This is probably a manifestation of an intermittent GDB bug [6].
We use the patch provided in the bug report to mitigate the effects
of that bug.

We also add a README in the recipe dir to warn maintainers and contributors that
it's possible that the automated testing starts failing when the Travis
CI macOS 10.13 image is decomissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: conda-forge#23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
[6]: https://sourceware.org/bugzilla/show_bug.cgi?id=24069
phil-blain added a commit to conda-forge/gdb-feedstock that referenced this issue Jul 8, 2020
@phil-blain
Merge pull request #23 from phil-blain/add-macos
4df33c4 
## Add support for building GDB on macOS

On macOS, debuggers need to be codesigned with a codesigning certificate located in the System keychain to be able to control other processes.

The script `recipe/macos-codesign/macos-setup-codesign.sh` sets up this certificate. It is taken from the [LLDB repository][1] and only slightly modified to use "gdb_codesign" as the certificate name. Using a script seems more robust than the manual method mentioned in the [GDB wiki][2]. 
This script requires 'sudo', so it is run automatically on the CI but not in a user installation. It is copied to the installation prefix so that users can run it after installing GDB.

The script `recipe/macos-codesign/macos-codesign-gdb.sh` actually calls `macos-setup-codesign.sh` and then signs the GDB executable using the just created certificate.

A post-link script runs the `recipe/macos-codesign/macos-codesign-gdb.sh` if passwordless sudo is available (in the CI), and if it's not, it writes to `$PREFIX/.messages.txt` such that users are notified that they need to sign GDB in order to use it, using the provided script.
**Note**: at the moment, conda mangles multi-line messages in `$PREFIX/.messages.txt` (conda/conda#8809 ). This bug was fixed in conda/conda#9841, which is already merged, and so should appear in conda 4.8.4. Maybe we want to wait for this conda release before merging this ? It would make for a nicer end-user experience, but since this message is also shown upon environment activation (as long as GDB is not codesigned), I think it's ok.

The message shown also informs users how to avoid being prompted for a password every login when they start an executable in GDB.

An activate script is also added to make sure that GDB is correctly codesigned upon environment activation. If it's not codesigned, users are instructed to run the provided script (by showing the same message as the post-link script). 

Here is a copy of the message users will see when installing (with the fix in  conda/conda#9841 applied to conda) :
```
Preparing transaction: done
Verifying transaction: done
Executing transaction: \ 

Codesigning GDB
---------------
Due to macOS security restrictions, the GDB executable 
needs to be codesigned to be able to control other processes.

The codesigning process requires the Command Line Tools
(or a full XCode installation). 
To install the Command Line Tools, run

  xcode-select --install

The codesigning process also requires administrative permissions
(your user must be able to run `sudo`).

To codesign GDB, simply run the included script:

  macos-codesign-gdb.sh

and enter your password. 

Make sure this environment, "<environment name>", is activated
so that "macos-codesign-gdb.sh" is found in your $PATH.

For more information, see: https://sourceware.org/gdb/wiki/PermissionsDarwin

Avoiding being prompted for a password
--------------------------------------
On recent macOS versions, you will be prompted for an administrator username and password
the first time you `run` an executable in GDB in each login session.

To instead be prompted for your own password,
you can add your user to the '_developer' group:

  sudo dscl . merge /Groups/_developer GroupMembership <username>

To avoid being prompted for any password, run

  sudo security authorizationdb write system.privilege.taskport allow


Showing this message again
--------------------------
Once GDB is codesigned, this message will disappear.
To show this message again, run

  macos-show-caveats.sh

done
#
# To activate this environment, use
#
#     $ conda activate gdb
#
# To deactivate an active environment, use
#
#     $ conda deactivate
```

Since the Python executable from the conda-forge python package does not include debugging symbols on macOS (see [3],[4]), we skip the test for the GDB "libpython" integration and add a simple "Hello World" C program, just to test that the debugger can actually run a program.

We use Travis CI for the macOS build since the conda-forge [Travis macOS image use macOS 10.13 ('xcode9.4')][5]. When tested under Azure and Travis under macOS 10.14 and 10.15, the build phase succeeds but when running the executable in GDB, GDB hangs. Doing manual testing on 10.15.5 I can replicate this behaviour about half the time I `run` an executable in GDB, so it looks like a race condition.

This is probably due to an [intermittent GDB bug][6]. The bug reporter suggests a patch that makes GDB not hang, but fails to launch the executable instead (again, about half the time it still works correctly). I've added this patch to the recipe and added a mention of that in `$PREFIX/.messages.txt` to inform users to just try again if they hit this bug:
```
Intermittent GDB error on Mojave and later
------------------------------------------
We've detected you are running macOS Mojave or later. GDB has a known intermittent bug on
recent macOS versions, see: https://sourceware.org/bugzilla/show_bug.cgi?id=24069

If you receive the following error when running your executable in GDB:

  During startup program terminated with signal ?, Unknown signal

simply try to `run` your executable again, it should work eventually.
```

We also add a README in the recipe dir to warn maintainers and contributors that it's possible that the automated testing starts failing when the Travis CI macOS 10.13 image is decommissioned (by Travis or conda-forge).

[1]: https://github.com/llvm/llvm-project/blob/master/lldb/scripts/macos-setup-codesign.sh
[2]: https://sourceware.org/gdb/wiki/PermissionsDarwin
[3]: #23
[4]: conda-forge/python-feedstock#354
[5]: https://docs.travis-ci.com/user/reference/osx/
[6]: https://conda-forge.org/docs/maintainer/infrastructure.html?highlight=skip#using-azure-for-everything
@pablogsal pablogsal mentioned this issue Aug 14, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@phil-blain