)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"8f905b6e7b56a234b6957e1a161551aa18741c79","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3549bbe5_a47149dd","updated":"2022-05-01 14:43:23.000000000","message":"This looks like a workaround for wrong .ld scripts with flash location at 0x0.\nIf the flash code is linked at 0x8000000, gdb selects breakpoint type correctly.\nIs there some good reason why the code should use the flash at mirrored location?","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"3a0bdb77361c8b2f556bdbb5a1f73a572498d4d8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8e97163c_703a464f","in_reply_to":"06581b7b_ac1fb096","updated":"2025-10-30 16:17:51.000000000","message":"\u003e The last line in the table 😊\n\nThanks, I missed that. You\u0027ve got valid points, and I don\u0027t think it really matters too much in practice, so I\u0027m happy to leave this unmerged unless/until someone else wants it too.","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"b1d55a632124ee5eeefd186ac2e3fa55e1cea1a7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"79a2c874_c0e98fec","in_reply_to":"3549bbe5_a47149dd","updated":"2025-10-28 14:04:34.000000000","message":"Code will work equally well linked at either location, so why shouldn\u0027t we support either location? I do believe that the official SDKs for this chip use 0x08000000 like you suggest, but other toolchains or handwritten assembly could just as easily use 0x00000000. Notably, the chip\u0027s reset vector is fixed at 0x00000000, so the first instruction out of a \"reset halt\" will always be in the alias.\n\nIs there a good reason we shouldn\u0027t include this alias, since it fixes behavior for some code and doesn\u0027t (to my knowledge) break it for any code?\n\n(Thought I sent this yesterday, but it got stuck as a draft.)","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"647e308f259824372c039662f42d6b03cc1b2cfd","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"492119fd_a4af0da2","in_reply_to":"3549bbe5_a47149dd","updated":"2025-10-28 10:50:00.000000000","message":"Please respond","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"a28166284175e378fe32008f7468cc12493a8d34","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ce8cb4c0_9cd64990","in_reply_to":"79a2c874_c0e98fec","updated":"2025-10-29 06:58:58.000000000","message":"\u003e (Thought I sent this yesterday, but it got stuck as a draft.)\n\nYes, this is not nice feature of gerrit that one has to click reply button to send comments.\n\nWell,  the situation of boot alias is very similar to STM32F1xx and numerous relative models. And nobody asked to configure the alias.\n\nThere is also the boot mode (I admit very rarely used) when the embedded RAM is aliased to the boot region. In that case the memory info would prevent gdb from inserting soft breakpoints (there is possible to enforce hw breakpoint by gdb hbreak command, no way to enforce soft break)\n\nDon\u0027t take it as a strict refusal. When more users put positive score I may re-think. But now I intentionally put no review score.","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"9998ceba4bda8ebf467aeebb2a92ba042c9add62","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"db7d82a4_bef25f38","in_reply_to":"ce8cb4c0_9cd64990","updated":"2025-10-30 15:26:51.000000000","message":"It\u0027s not just \"break\" that fails: single-stepping in the aliased region also doesn\u0027t work, since GDB tries to make a soft single-step breakpoint, which fails and never fires. So \"si\" and \"ni\" both act like \"c\". The same issue prevents explicit \"hbreak\" points from firing a second time after they\u0027re hit once, since part of gdb\u0027s process for continuing from a breakpoint is to single-step off it. Everything works correctly with the alias defined.\n\nI acknowledge that most real code probably won\u0027t require breakpoints in the aliased region, which is probably why no one added a similar alias to the STM configs. But I don\u0027t think \"other configs don\u0027t handle it properly\" is a good reason for this config to also not handle it properly.\n\nI also acknowledge that the alias isn\u0027t semantically correct when the bootloader is running, in which case 0x00000000 points to ROM and not flash. But it is functionally correct, since ROM is also read-only. I\u0027m not aware of a way to alias RAM to 0x00000000 on this chip; can you elaborate on that? The User Manual from GigaDevice[1] states that it may alias either main flash or the bootloader.\n\n[1] https://download.gigadevice.com/User_Manual/GD32VF103_User_Manual_Rev1.8.pdf","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"58456f3e5f1ef7364f2fd706c9bb2921a673d75f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"06581b7b_ac1fb096","in_reply_to":"db7d82a4_bef25f38","updated":"2025-10-30 16:09:54.000000000","message":"\u003e It\u0027s not just \"break\" that fails: single-stepping in the aliased region also doesn\u0027t work, since GDB tries to make a soft single-step breakpoint, ...\n\nYes, this is annoying bug of many versions of gdb. You should better complain at https://sourceware.org/bugzilla/\nBTW recently I compiled gdb 16.2 from the official source and it issues real steps (vCont;s in remote protocol) instead of temp BP vCont;c workaround used for unknown reason.\n\n\u003e I\u0027m not aware of a way to alias RAM to 0x00000000 on this chip; can you elaborate on that? The User Manual from GigaDevice[1] states that it may alias either main flash or the bootloader.\n\u003e \n\u003e [1] https://download.gigadevice.com/User_Manual/GD32VF103_User_Manual_Rev1.8.pdf\n\nIn that file\nchapter `1.4. Boot configuration`, Table 1-3. Boot modes\nThe last line in the table 😊","commit_id":"0ef135de01bf814df4e486d3fb47ece2ac644d53"}]}