A few targets supported by BMD contain executable but read-only memory, which is not declared in the qXfer:memory-map sent to GDB. set inaccessible-by-default off is the quick workaround for this. However, then GDB will treat it as RAM, attempt to write to it (e.g. to set software breakpoints). Per documentation GDB supports <memory type="rom" start="0x1fff0000" length="0x7800"/> entries. BMD only generates type="ram" entries. BMD is tailored for debug from rewritable flash and RAM.
Examples 1: system memory bootloaders in STM32, Boot ROMs in Cortex-A. I could only find limited use for this, as in, I set a hardware breakpoint on AN2606 bootloader entrypoint, and get notified whenever STM32F411CE target attempts to reboot to DfuSe; or, I dumped hex memory of STM32MP15x BootROM and used that for 128 KiB compare-sections benchmark of cortexar_mem_read() routines and SWD/JTAG transport. Registering every such bootloader might bloat BMF (a function call with 3 arguments). Some Nordic chips famously have no bootloader.
Examples 2: RP2040 bootrom, which implements UF2 and Quinapalus softfloat library in 16 KiB; RP2350 bootrom, which contains UF2 in NSBoot and some flash routines; ESP32-C3/C6 ROM code, LPC chip IAP flash services, HPMicro HPM5E00 ROM API with flash services. In contrast, having these mapped suitably for GDB to auto-pick hardware breakpoints, should help during development of BMD flash drivers relying on such ROM code. Some chips are marketed as having faster/optimized routines in ROM outside the contested data bus fetch paths, and the routines have a public API and a pointer table, to be called from user firmware.
RFC: add new functions, i.e. target_add_rom32() that behave like target_add_ram32(), but instead of appending to a linked list of struct target_ram, either append to a similar linked list of struct_target_ram held in new target->rom pointer, or only allow registering a single region; and then expose it in the exec_q_memory_map()/target_mem_map_chunk() generator as mem_map_rom() method. Aforementioned target drivers would register suitable regions in a single call. I don't think BMF flash size impact would be large; RAM impact is 12 bytes per struct on heap (plus malloc housekeeping).
A few targets supported by BMD contain executable but read-only memory, which is not declared in the qXfer:memory-map sent to GDB. `set inaccessible-by-default off` is the quick workaround for this. However, then GDB will treat it as RAM, attempt to write to it (e.g. to set software breakpoints). Per [documentation](https://www.sourceware.org/gdb/current/onlinedocs/gdb.html/Memory-Map-Format.html) GDB supports `<memory type="rom" start="0x1fff0000" length="0x7800"/>` entries. BMD only generates `type="ram"` entries. BMD is tailored for debug from rewritable flash and RAM.
Examples 1: system memory bootloaders in STM32, Boot ROMs in Cortex-A. *I could only find limited use for this, as in, I set a hardware breakpoint on [AN2606 bootloader](https://www.st.com/resource/en/application_note/an2606-introduction-to-system-memory-boot-mode-on-stm32-mcus-stmicroelectronics.pdf) entrypoint, and get notified whenever STM32F411CE target attempts to reboot to DfuSe; or, I dumped hex memory of STM32MP15x [BootROM](https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview) and used that for 128 KiB compare-sections benchmark of cortexar_mem_read() routines and SWD/JTAG transport.* Registering every such bootloader might bloat BMF (a function call with 3 arguments). Some Nordic chips famously have no bootloader.
Examples 2: [RP2040 bootrom](https://github.com/raspberrypi/pico-bootrom-rp2040), which implements UF2 and Quinapalus softfloat library in 16 KiB; [RP2350 bootrom](https://github.com/raspberrypi/pico-bootrom-rp2350), which contains UF2 in NSBoot and some flash routines; ESP32-C3/C6 [ROM code](https://github.com/espressif/esp-rom-elfs), LPC chip IAP flash services, HPMicro [HPM5E00 ROM API](https://www.hpmicro.com/Public/Uploads/uploadfile2/files/20260324/HPM5E00UMENV0.3.pdf) with flash services. In contrast, having these mapped suitably for GDB to auto-pick hardware breakpoints, should help during development of BMD flash drivers relying on such ROM code. Some chips are marketed as having faster/optimized routines in ROM outside the contested data bus fetch paths, and the routines have a public API and a pointer table, to be called from user firmware.
RFC: add new functions, i.e. target_add_rom32() that behave like target_add_ram32(), but instead of appending to a linked list of `struct target_ram`, either append to a similar linked list of `struct_target_ram` held in new `target->rom` pointer, or only allow registering a single region; and then expose it in the exec_q_memory_map()/target_mem_map_chunk() generator as `mem_map_rom()` method. Aforementioned target drivers would register suitable regions in a single call. I don't think BMF flash size impact would be large; RAM impact is 12 bytes per struct on heap (plus malloc housekeeping).