Fix size of struct breakpoint #2262

ALTracer commented 2026年05月23日 23:15:23 +02:00

Detailed description

• No new features.
• The existing problem is incomplete change from #2017 that should reshuffle fields of struct breakpoint for alignment.
• This pull request solves it by adding a static assert and adjusting meson flags.

-DCONFIG_POINTER_SIZE=8 should be present in ninja logs in gcc arguments, because that is a preprocessor define for the compiler, but I didn't see it. As I was looking around usage of breakpoint->reserved[0] etc. I've noticed that the struct can still have a different size depending on arch (BMDA/amd64 or BMF/armv7-m), as in, static assert fails, or passes for different sizeof() values. I can agree that RAM layout of these doesn't need to be binary compatible with anything. If the static assert is unwanted (nothing else uses it in the codebase), then I'll discard the first commit of the two.
Meson add_project_link_arguments() only appends to linker flags, but by then it's too late to take effect. Let's promote it to add_project_arguments().
Tested on Meson 1.8.2. CC @marysaka

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

## Detailed description * No new features. * The existing problem is incomplete change from #2017 that should reshuffle fields of `struct breakpoint` for alignment. * This pull request solves it by adding a static assert and adjusting meson flags. `-DCONFIG_POINTER_SIZE=8` should be present in ninja logs in gcc arguments, because that is a preprocessor define for the compiler, but I didn't see it. As I was looking around usage of `breakpoint->reserved[0]` etc. I've noticed that the struct can still have a different size depending on arch (BMDA/amd64 or BMF/armv7-m), as in, static assert fails, or passes for different sizeof() values. I can agree that RAM layout of these doesn't need to be binary compatible with anything. If the static assert is unwanted (nothing else uses it in the codebase), then I'll discard the first commit of the two. Meson `add_project_link_arguments()` only appends to linker flags, but by then it's too late to take effect. Let's promote it to `add_project_arguments()`. Tested on Meson 1.8.2. CC @marysaka ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [x] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues

ALTracer commented 2026年06月20日 01:38:03 +02:00

Rebased trivially across 2266 for a clean fast-forward style merge

Rebased trivially across 2266 for a clean fast-forward style merge

northernpaws commented 2026年06月20日 02:43:43 +02:00

Many thanks! We’re just waiting on Codeberg CI to recover from an outage so the CI checks can pass.

Many thanks! We’re just waiting on Codeberg CI to recover from an outage so the CI checks can pass.