Skip to content

Commit

Permalink
More debugging documentation
Browse files Browse the repository at this point in the history
There are a few things I think people should know, post-Meson.
  • Loading branch information
Ericson2314 committed Feb 3, 2025
1 parent cba27ba commit 243467e
Show file tree
Hide file tree
Showing 3 changed files with 39 additions and 18 deletions.
20 changes: 5 additions & 15 deletions doc/manual/source/development/building.md
Original file line number Diff line number Diff line change
Expand Up @@ -167,24 +167,18 @@ It is useful to perform multiple cross and native builds on the same source tree
for example to ensure that better support for one platform doesn't break the build for another.
Meson thankfully makes this very easy by confining all build products to the build directory --- one simple shares the source directory between multiple build directories, each of which contains the build for Nix to a different platform.

Nixpkgs's `configurePhase` always chooses `build` in the current directory as the name and location of the build.
This makes having multiple build directories slightly more inconvenient.
The good news is that Meson/Ninja seem to cope well with relocating the build directory after it is created.
Here's how to do that:

Here's how to do that

1. Configure as usual
1. Instruct Nixpkgs's infra where we want Meson to put its build directory

```bash
configurePhase
mesonBuildDir=build-my-variant-name
```

2. Rename the build directory
1. Configure as usual

```bash
cd .. # since `configurePhase` cd'd inside
mv build build-linux # or whatever name we want
cd build-linux
configurePhase
```

3. Build as usual
Expand All @@ -193,10 +187,6 @@ Here's how to do that
buildPhase
```

> **N.B.**
> [`nixpkgs#335818`](https://github.com/NixOS/nixpkgs/issues/335818) tracks giving `mesonConfigurePhase` proper support for custom build directories.
> When it is fixed, we can simplify these instructions and then remove this notice.
## System type

Nix uses a string with the following format to identify the *system type* or *platform* it runs on:
Expand Down
11 changes: 11 additions & 0 deletions doc/manual/source/development/debugging.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

This section shows how to build and debug Nix with debug symbols enabled.

Additionally, see [Testing Nix](./testing.md) for further instructions on how to debug Nix in the context of a unit test or functional test.

## Building Nix with Debug Symbols

In the development shell, set the `mesonBuildType` environment variable to `debug` before configuring the build:
Expand All @@ -13,6 +15,15 @@ In the development shell, set the `mesonBuildType` environment variable to `debu
Then, proceed to build Nix as described in [Building Nix](./building.md).
This will build Nix with debug symbols, which are essential for effective debugging.

It is also possible to build without debugging for faster build:

```console
[nix-shell]$ NIX_HARDENING_ENABLE=$(printLines $NIX_HARDENING_ENABLE | grep -v fortify)
[nix-shell]$ export mesonBuildType=debug
```

(The first line is needed because `fortify` hardening requires at least some optimization.)

## Debugging the Nix Binary

Obtain your preferred debugger within the development shell:
Expand Down
26 changes: 23 additions & 3 deletions doc/manual/source/development/testing.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,14 +87,34 @@ A environment variables that Google Test accepts are also worth knowing:
This is used to avoid logging passing tests.
Putting the two together, one might run
3. [`GTEST_BREAK_ON_FAILURE`](https://google.github.io/googletest/advanced.html#turning-assertion-failures-into-break-points)
This is used to create a debugger breakpoint when an assertion failure occurs.
Putting the first two together, one might run
```bash
GTEST_BRIEF=1 GTEST_FILTER='ErrorTraceTest.*' meson test nix-expr-tests -v
```
for short but comprensive output.

### Debugging tests

For debugging, it is useful to combine the third option above with Meson's [`--gdb`](https://mesonbuild.com/Unit-tests.html#other-test-options) flag:

```bash
GTEST_BRIEF=1 GTEST_FILTER='Group.my-failing-test' meson test nix-expr-tests --gdb
```

This will:

1. Run the unit test with GDB

2. Run just `Group.my-failing-test`

3. Stop the program when the test fails, allowing the user to then issue arbitrary commands to GDB.

### Characterisation testing { #characaterisation-testing-unit }

See [functional characterisation testing](#characterisation-testing-functional) for a broader discussion of characterisation testing.
Expand Down Expand Up @@ -213,10 +233,10 @@ edit it like so:
bar
```

Then, running the test with `./mk/debug-test.sh` will drop you into GDB once the script reaches that point:
Then, running the test with [`--interactive`](https://mesonbuild.com/Unit-tests.html#other-test-options) will prevent Meson from hijacking the terminal so you can drop you into GDB once the script reaches that point:

```shell-session
$ ./mk/debug-test.sh tests/functional/${testName}.sh
$ meson test ${testName} --interactive
...
+ gdb blash blub
GNU gdb (GDB) 12.1
Expand Down

0 comments on commit 243467e

Please sign in to comment.