)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"d3054babdd547dd8331f8ef96652a3dc0a1a3ee7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d7c451e8_f93793f4","updated":"2021-09-05 20:49:25.000000000","message":"Dietmar May wrote:\n \u003e ... I\u0027m working on a multi-core SMP system where the cores are running independent of each other, ...\n\nIn openocd the concept of SMP is related to the debugging activity of the SW running on the cores.\n\nIn SMP mode openocd opens a single GDB port and the single GDB attached will debug a single program split in threads running on the SMP cores.\n\nIf the cores are running independently, then you should disable SMP before openocd \u0027init\u0027.\nWith SMP disabled, each core will open a GDB port, so you can connect multiple GDB, each GDB debugging its own independent program.\n\nYou can split the N cores of your SMP SoC in any subgroup, e.g. one core independent and the (N-1) cores in one SMP node. This will open 2 GDB ports.\n\nThen it\u0027s up to the openocd user to list in the \"target smp\" command the cores he/she wants.\nMixing Cortex-M4 with Cortex-A57 will not work (Tim\u0027s code checks that registers have the same size). Mixing Cortex-M4 with Cortex-A5 will probably work from register\u0027s point of view. I want to check if there is any other constraint in openocd code. For sure \u0027cortex_a smp off\u0027 doesn\u0027t work with Cortex-M4.\n\n \u003e ... may I politely suggest that you look at a way to selectively enable this by adding or updating an openocd command?\nYes, this is an interesting option. But user has already the option of not listing cores in \"target smp\" command.\n\n \u003e ... as you mentioned, by doing this, GDB will report errors for one of the cores, on your processor.\nThis is damned important.\nIn Tim\u0027s code ALL the registers of first core and any new register from the other cores will print a debug message \"[%s] %s not found in combined list\". This message is only for debugging this piece of code; doesn\u0027t carry any info to the user.\nI would like to have a set of LOG_INFO() to the user, saying something like: \"cores in SMP group are heterogeneous\" and \"core %d don\u0027t have registers: %s, %s, ...\".\nThen if GDB asks a non-existing register dynamically added here, GDB should not fail, but openocd should:\n- dump a warning \"GDB read from non-existing register %s, virtually added to heterogeneous SMP cluster. Send zero value\"\n- dump a warning \"GDB write to non-existing register %s, virtually added to heterogeneous SMP cluster. Discard write\"\n","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001918,"name":"Dietmar May","email":"dietmar.may@outlook.com","username":"dmay"},"change_message_id":"6b7a07d27d04c6a33cfc9b97951947fdd8748c8d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"eb33c0f4_e0a5b70c","updated":"2021-08-27 00:07:23.000000000","message":"Hi Tim,\n\nThe code looks fairly straightforward.\n\nSerious question. What if it is NOT helpful to pretend that my heterogenous multi-core system is homogeneous?\n\nIn other words, say I\u0027m working on a multi-core SMP system where the cores are running independent of each other, and I don\u0027t want to see, be confused by, or have to wade through a mess of registers from cores that are not actively being debugged?\n\nHow can this mode be enabled, so it\u0027s useful for you, and disabled, so it\u0027s not a pain for me?\n\nWhat about, instead of trying to inspect registers for other cores using gdb, use the OpenOCD telnet prompt?\n\nI submitted, among other patches, a couple of enhancements to (a) show which core is being displayed, and (b) allow registers for a specific core to be queried, not just for the last processor to halt.\n\nhttps://review.openocd.org/c/openocd/+/6477\n\nSo you would connect (telnet -4 localhost 4444), and when GDB hits a breakpoint, you could type: \n\nca57.3 aarch64 reg\n\nto inspect the registers for core 4, and then \n\nca57.1 aarch64 reg\n\nto inspect the registers for core 2.\n\nLooks like you\u0027re on a RISC-V platform; but the same code should port to the risc target.\n\nDietmar","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001918,"name":"Dietmar May","email":"dietmar.may@outlook.com","username":"dmay"},"change_message_id":"920c6e59b43767607ee0432d9ab5581dfccc8aea","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4ce57448_fc50c01f","in_reply_to":"0dff5369_8b3b8d57","updated":"2021-09-22 16:01:32.000000000","message":"Unexpected / unexplained errors are a good way to ensure ongoing support requests :-).\n\nI had to build and debug OpenOCD code in order to figure out why some commands were not working. With the pressure of tight deadlines, it was not fun.\n\n0xdeadbeef for all missing registers?\n\nAlso, is there any way to provide a status message to the user at some point - a dump to telnet / output? At target definition? Maybe in \"$target halted in ... state due to debug-request\"? Add \", core has missing registers\"?","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"c7891948440d8eda1f4ec8473b5c5e3b1e9cae5a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"655f1045_2c539e12","in_reply_to":"1916119c_796ed04b","updated":"2021-09-21 08:06:04.000000000","message":"The problem is that user get no info why there is an error nor that error is expected.\nI\u0027m checking GDB source code. The string \u0027E0E\u0027 is made by OpenOCD gdb_send_error() where the \u00270E\u0027 is the value of 14 of EFAULT.\nApparently undocumented, GDB also accepts receiving \u0027E.\u0027 followed by a string for errors.\nCould be nice to extend gdb_send_error() and in this specific case report GDB something like \u0027E. Register %s not present in core %d\u0027.\nBut before acknowledging this change, I want to check if LLDB accepts it too.\nAnyway this cannot be a general change for all the errors, as I see some inconsistency in GDB source code; but so far, limited to single register R/W it should be ok (for GDB only, so far).","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"9f065cb553f12dfc74a11e1921a328226ad7e91a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"958238db_5d4c2987","in_reply_to":"2f7125b6_534f9e58","updated":"2021-10-05 18:23:47.000000000","message":"So... Where is this at?\n\nDid I convince anybody that it\u0027s better to return an error than a magic value?\n\nAntonio, what do you think is the change I should be making?","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"265db1af9a07e09a3d86e43a713dd507a8cf20a6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2f7125b6_534f9e58","in_reply_to":"4ce57448_fc50c01f","updated":"2021-09-22 16:20:53.000000000","message":"\u003e Unexpected / unexplained errors are a good way to ensure ongoing support requests :-).\n\nYes, but magic values are even more mysterious. At least when there\u0027s an error it\u0027s clear the register wasn\u0027t read.\n\nIf I ask you to read the first page of War And Peace then I\u0027d much rather have you say \"I couldn\u0027t read it\" than to read me \"Lorem ipsum ...\" instead.\n\nI\u0027m not aware of a way that OpenOCD can return anything helpful to gdb.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"1cb030f776bd92903d69333804f2f10ce117bf1c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6c669852_95cbd06f","in_reply_to":"60113160_21eda877","updated":"2021-09-17 20:35:39.000000000","message":"Done","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"cf513f97df05da7ee2f0b7fa959c6e2e09a7e8c5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e6322e75_bf745a57","in_reply_to":"655f1045_2c539e12","updated":"2021-09-21 10:03:54.000000000","message":"Looks like LLDB has a completely different way to handle remote GDB errors\nhttps://github.com/llvm/llvm-project/blob/main/lldb/source/Utility/StringExtractorGDBRemote.cpp#L23\nIt accepts only \u0027Exx\u0027 with \u0027x\u0027 an hex digit, with extension (from quick decrypting of this crap c++) \u0027Exx;xxxxxxxx\u0027 with as many extra hex digits.\n\nI\u0027m not aware of a method to let openocd detect gdb vs lldb at connection.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001918,"name":"Dietmar May","email":"dietmar.may@outlook.com","username":"dmay"},"change_message_id":"2e31ee0af22be3cc1ee6c93d6c477a2634cac0f3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"83fe10a9_15a2a355","in_reply_to":"6dc0ca93_01005e1b","updated":"2021-08-27 19:59:27.000000000","message":"This sounds kind of like have 4 Cortex A57 cores plus a Cortex M4 on a single chip? and the M4 is relagated to housekeeping or I/O tasks while the A57\u0027s do the real work?\n\nSo maybe trying to model all of the cores as the same type - ie. homogenous - when they\u0027re not is a problem?\n\n1) Maybe create another target, don\u0027t add it to the SMP group, and AIR, openocd will create another gdbserver instance on 3334. Then connect 2 instances of GDB to your target - port 3333 debugging the 4 homogenous cores, and port 3334 debugging the odd man out.\n\nSomething like (this is for ARM):\n\njtag newtap acme tap -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0xdeadbeef -enable\ndap create acme.dap -chain-position acme.tap\n\nproc init_targets {} {\n    global _CHIPNAME\n    set _cores 4\n\n    set _DBGBASE {0xC0110000 0xC0210000 0xC0310000 0xC0410000 0xC0510000}\n    set _CTIBASE {0xC0120000 0xC0220000 0xC0320000 0xC0420000 0xC0520000}\n\n    # configure ARM Cross Trigger interfaces for all cores\n    for { set _core 0 } { $_core \u003c $_cores } { incr _core } {\n        cti create cti_acme.$_core -dap acme.dap -ap-num 0 -baseaddr [lindex $_CTIBASE $_core]\n    }\n    cti create cti_acme.$_core -dap acme.dap -ap-num 0 -baseaddr [lindex $_CTIBASE $_core]\n\n    for { set _core 0 } { $_core \u003c $_cores } { incr _core } {\n        target create acme.$_core aarch64 -dap acme.dap -coreid $_core \\\n            -dbgbase [lindex $_DBGBASE $_core] -cti cti_acme.$_core\n        # Show cores as HW threads\n        acme.$_core configure -rtos hwthread\n    }\n\n    # Configure all cores as SMP, start only one GDB server for all 4 on 3333\n    target smp acme.0 acme.1 acme.2 acme.3\n\n    # Create another target for extra core, start another GDB server on 3334\n    target create acme.4 aarch64 -dap acme.dap -ap-num 0 -dbgbase [lindex $_CTIBASE 5]\n}\n\n2) Or maybe define your core 0 as core 4 instead? With this, I would expect openocd to send gdb the full list of HiFive registers for core 1 (which you\u0027ve told openocd is core 0, so it now knows about the FPRs). Then when you see the errors on core 4 (ie. core 0) for the missing registers, it won\u0027t confuse you because you\u0027re expecting that.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"3b605196a50b6505512306451f228aa2154d0a09","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9edb8b89_073bb117","in_reply_to":"83fe10a9_15a2a355","updated":"2021-08-27 20:20:03.000000000","message":"\u003e So maybe trying to model all of the cores as the same type - ie. homogenous - when they\u0027re not is a problem?\n\nAgreed, but we have customers who want to see all the cores together. Having a separate gdb instance when all cores are really running the same software makes debugging more complicated.\n\n\u003e Or maybe define your core 0 as core 4 instead?\n\nThen we need to teach people that, when debugging, the core numbers are not the same as the core ids in the system. That\u0027s bound to lead to confusion.\n\nYou are right that there are other ways to work around the problem, but I\u0027m still not sure what the downside to this solution is. If you want to do it right (by only grouping truly homogeneous cores together) then this change doesn\u0027t affect anything. And if you do group heterogeneous cores together then at least you can access every register on each core, which currently you cannot.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001918,"name":"Dietmar May","email":"dietmar.may@outlook.com","username":"dmay"},"change_message_id":"83c3a21997b13c42a1517d44766af361782df03a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"60113160_21eda877","in_reply_to":"9edb8b89_073bb117","updated":"2021-08-27 21:01:25.000000000","message":"Yes, but as you mentioned, by doing this, GDB will report errors for one of the cores, on your processor.\n\n\u003e For core 0 the FPRs will show up with an error message. \n\nThe same will happen on other processors, which is bound to be confusing to other openocd users.\n\nYou\u0027re looking at it like \"This will make my customer\u0027s job a lot easier\". I\u0027m looking at it like \"This may make someone else\u0027s job more confusing, when they get unknown error messages and try to figure out what\u0027s wrong with their hardware\".\n\nI lost more than a little time because openocd was silently ignoring an important command. Turns out it was because the processor wasn\u0027t halted - but it took pulling down source code, building, and stepping through the code to figure that out.\n\nI just don\u0027t want somebody else to have to go through that, to figure out why they\u0027re seeing errors for registers that don\u0027t exist. At least your users can contact your engineers who get paid to  explain things. Most users have to hope that somebody who doesn\u0027t get paid will take time out of their busy day to respond - as I did to you.\n\nIf neither of these options is viable for you, may I politely suggest that you look at a way to selectively enable this by adding or updating an openocd command? (\"target reg union\"? or maybe on the TAP?) That way, someone only sees this behavior if they explicity enable it, which hopefully means they\u0027re not confused about why the errors show up.\n\nBTW, I don\u0027t have signoff rights on openocd. I\u0027m just another user like you. So before investing time into further changes, may be best to wait until someone who *can* sign off weighs in.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"4697294ad755c3fb5cb61f5cc977ed7ac97a5d8f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"deea7179_209c60b4","in_reply_to":"d7c451e8_f93793f4","updated":"2021-09-18 15:06:42.000000000","message":"Tim, this is not resolved\n- user is not informed that there are different register-maps in the SMP cluster;\n- GDB reports error on non-existing registers.\nDo you think these items could be addressed?","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"80a089bca601b2966debe9c68abaf97cbfee8a97","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1916119c_796ed04b","in_reply_to":"deea7179_209c60b4","updated":"2021-09-20 22:02:59.000000000","message":"\u003e user is not informed that there are different register-maps in the SMP cluster;\n\nI\u0027ll do that. Shouldn\u0027t be too bad.\n\n\u003e GDB reports error on non-existing registers.\n\nI think to do that right I\u0027d have to track for each register whether we want to report errors to gdb or not. Is that what you have in mind? What exactly is the problem with reporting an error to gdb? E.g.:\n```\n(gdb) info registers ft0\nft0            Could not fetch register \"ft0\"; remote failure reply \u0027E0E\u0027\n(gdb) p/x $ft0\nCould not fetch register \"ft0\"; remote failure reply \u0027E0E\u0027\n(gdb) thread 2\n[Switching to thread 2 (Thread 2)]\n#0  0x0000000008001a18 in ?? ()\n(gdb) info registers ft0\nft0            {float \u003d 0, double \u003d -nan(0xfffff00000000)}\t(raw 0xffffffff00000000)\n(gdb) p/x $ft0\n$1 \u003d {float \u003d 0x0, double \u003d 0x7fffffffffffffff}\n```","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"4fb8a1d1da76ab4d556fc70cce35185b35052f90","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0dff5369_8b3b8d57","in_reply_to":"e6322e75_bf745a57","updated":"2021-09-21 17:10:56.000000000","message":"\u003e The problem is that user get no info why there is an error nor that error is expected.\n\nSure, but is it better to return a dummy value and no error? I think it\u0027s more surprising to a user to have gdb report a value (e.g. 0) when reading a register that doesn\u0027t exist than it is to report an error. At least the error makes it clear that something unusual is going on. With the warnings in the log I just added I think debugging such a case will be fairly straightforward. (User emails complaining they get errors in gdb, somebody suggests looking at the OpenOCD output, which will quickly reveal the warnings.)","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"8e1aee72c07c25b55d99b7357d369e34807692bb","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6dc0ca93_01005e1b","in_reply_to":"eb33c0f4_e0a5b70c","updated":"2021-08-27 16:36:10.000000000","message":"\u003e Serious question. What if it is NOT helpful to pretend that my heterogenous multi-core system is homogeneous?\n\ngdb always pretends the cores you give it are homogeneous. The only way to fix that is to change gdb.\n\n\u003e In other words, say I\u0027m working on a multi-core SMP system where the cores are running independent of each other, and I don\u0027t want to see, be confused by, or have to wade through a mess of registers from cores that are not actively being debugged?\n\nIt sounds like you imagine this change results in gdb always showing the contents of each register on each core. That is not the case.\n\nConsider HiFive Unleashed, which has 5 cores. Core 0 only contains GPRs (general-purpose registers like stack pointer and so on), while cores 1--4 contain GPRs and FPRs (floating point registers). When using `target smp` to expose all these cores to gdb together, OpenOCD transmits a list of register names to gdb. gdb takes this list, and assumes that every core has those registers (and no other ones). In the current implementation OpenOCD takes the registers from the first core in the list. In this example that means it transmits the list of GPRs. So from gdb it is now impossible to access the FPRs for cores that have them because, as far as gdb is concerned, those registers don\u0027t exist. Regardless of which core is the currently selected one, `info registers all` will just show the GPRs for the currently selected core.\n\nWith this change, when gdb connects then OpenOCD will transmit a list that includes the names of each GPR and also of each FPR. gdb assumes that every core has GPRs and FPRs. `info registers all` will, for the currently selected core, show those registers. For core 0 the FPRs will show up with an error message. (gdb already has built-in register groups, so you\u0027re not looking at the FPRs all the time unless you explicitly ask for them.)\n\nDoes that sound more reasonable? If not, can you explain in a bit more detail the problem you predict?\n\n\u003e What about, instead of trying to inspect registers for other cores using gdb, use the OpenOCD telnet prompt?\n\nFor my use case that\u0027s a lot more hassle.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"1cb030f776bd92903d69333804f2f10ce117bf1c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f79b3b13_7226e663","updated":"2021-09-17 20:35:39.000000000","message":"Marking this resolved based on Antonio\u0027s explanation.","commit_id":"a77cfb218b82a3acb62e70d40c325cd6fa5a8665"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"3c0b92437b03563016e6c9f5299daf85a064a7c0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"54c38bfc_ffd2c766","updated":"2021-11-09 18:25:40.000000000","message":"Can somebody help me figure out what I need to do to get this change accepted?","commit_id":"93363a06357d075cdbfd17c51965c3058e24b3c5"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"a772b980334aff42f9f8257952eeb83930490c55","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"172fb56c_8cc18df3","updated":"2021-12-02 18:50:43.000000000","message":"I think this change is good to go. If not, what do I need to do to get it there?","commit_id":"93363a06357d075cdbfd17c51965c3058e24b3c5"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"4c9a7e65b980c24b804b6f023f3dedc9b29f19b7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5d0c12d1_63037410","updated":"2022-01-21 15:52:46.000000000","message":"Sorry for taking log time.\nI don\u0027t find a way to communicate the error\u0027s reason consistently with both GDB and LLDB.\nLet\u0027s merge this, as is, and keep the error improvement in our wish list.\nI\u0027m investigating if I can detect GDB vs LLDB. The detection could help the future improvement.\nIf no complains, I will merge this in one week.","commit_id":"93363a06357d075cdbfd17c51965c3058e24b3c5"},{"author":{"_account_id":1001891,"name":"Michele Bisogno","email":"michele.bisogno.ct@renesas.com","username":"MicBiso"},"change_message_id":"6748cec4bc87a95004c094db1e949d1cf4d6d2e2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0c3e3e10_6a72f830","in_reply_to":"5d0c12d1_63037410","updated":"2022-02-19 09:38:21.000000000","message":"This patch causes OpenOCD to crash when a gdb connection to my target (RZ/G2L) is attempted:\n\nError: 52521 3649 target.c:1437 target_get_gdb_reg_list(): Target not examined yet\nError: 52522 3649 gdb_server.c:2381 gdb_generate_target_description(): get register list failed\ndouble free or corruption (!prev)\nDebug: 52523 3649 server.c:613 sig_handler(): Terminating on Signal 6\nAborted (core dumped)\n\nThe double free is due to the free(reg_list) below:\n\nerror:\n\tfree(features);\n\tfree(reg_list);\n\n\tif (retval \u003d\u003d ERROR_OK)\n\t\t*tdesc_out \u003d tdesc;\n\telse\n\nof the gdb_generate_target_description function in gdb_server.c\n\nI suspect this is related to the fact that in my case both CA55s belong to the smp targets even if the second CA55 is not examined because in power down after reset.\n\nI think there are many cases this is done and definitely OpenOCD shall not crash.","commit_id":"93363a06357d075cdbfd17c51965c3058e24b3c5"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"0be22632fcebb42d95bff9297f4b064879a44e82","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"8997e09d_5d516545","updated":"2022-03-09 19:12:15.000000000","message":"Resolving because it\u0027s \"my turn\"","commit_id":"6541233aa78d40200092920ec4a72e3917ae3b6d"},{"author":{"_account_id":1001891,"name":"Michele Bisogno","email":"michele.bisogno.ct@renesas.com","username":"MicBiso"},"change_message_id":"6748cec4bc87a95004c094db1e949d1cf4d6d2e2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"cce68a8c_f0462c13","updated":"2022-02-19 09:38:21.000000000","message":"This patch causes OpenOCD to crash when a gdb connection to my target (RZ/G2L) is attempted:\n\nError: 52521 3649 target.c:1437 target_get_gdb_reg_list(): Target not examined yet\nError: 52522 3649 gdb_server.c:2381 gdb_generate_target_description(): get register list failed\ndouble free or corruption (!prev)\nDebug: 52523 3649 server.c:613 sig_handler(): Terminating on Signal 6\nAborted (core dumped)\n\nThe double free is due to the free(reg_list) below:\n\nerror:\n\tfree(features);\n\tfree(reg_list);\n\n\tif (retval \u003d\u003d ERROR_OK)\n\t\t*tdesc_out \u003d tdesc;\n\telse\n\nof the gdb_generate_target_description function in gdb_server.c\n\nI suspect this is related to the fact that in my case both CA55s belong to the smp targets even if the second CA55 is not examined because in power down after reset.\n\nI think there are many cases this is done and definitely OpenOCD shall not crash.\n\n","commit_id":"6541233aa78d40200092920ec4a72e3917ae3b6d"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"5814e990ea5d28bbb127fd17e0e623d5ac88aa11","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"e4eea476_44c32dcf","in_reply_to":"cce68a8c_f0462c13","updated":"2022-02-19 15:36:58.000000000","message":"Thanks for reporting it.\nI have pushed https://review.openocd.org/6852/ to solve the double free only, but I think it\u0027s still not enough for the case of one target not examined. I will send another patch for this additional issue.\nIn mean time, a review of 6852 could help speeding-up the merge.","commit_id":"6541233aa78d40200092920ec4a72e3917ae3b6d"}],"src/server/gdb_server.c":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"86eb00d5c90c9f80ade844ecea22088a10d4c28c","unresolved":true,"context_lines":[{"line_number":2263,"context_line":"\t\treturn target_get_gdb_reg_list_noread(target, combined_list,"},{"line_number":2264,"context_line":"\t\t\t\tcombined_list_size, REG_CLASS_ALL);"},{"line_number":2265,"context_line":""},{"line_number":2266,"context_line":"\tint combined_allocated \u003d 256;"},{"line_number":2267,"context_line":"\t*combined_list \u003d malloc(combined_allocated * sizeof(struct reg *));"},{"line_number":2268,"context_line":"\tif (*combined_list \u003d\u003d NULL) {"},{"line_number":2269,"context_line":"\t\tLOG_ERROR(\"malloc(%d) failed\", (int) (combined_allocated * sizeof(struct reg *)));"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"58357896_57e29adf","line":2266,"updated":"2021-09-05 20:55:51.000000000","message":"unsigned int","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"dd90fb24fe96043dc4e5062834ce0125d6c4bf97","unresolved":false,"context_lines":[{"line_number":2263,"context_line":"\t\treturn target_get_gdb_reg_list_noread(target, combined_list,"},{"line_number":2264,"context_line":"\t\t\t\tcombined_list_size, REG_CLASS_ALL);"},{"line_number":2265,"context_line":""},{"line_number":2266,"context_line":"\tint combined_allocated \u003d 256;"},{"line_number":2267,"context_line":"\t*combined_list \u003d malloc(combined_allocated * sizeof(struct reg *));"},{"line_number":2268,"context_line":"\tif (*combined_list \u003d\u003d NULL) {"},{"line_number":2269,"context_line":"\t\tLOG_ERROR(\"malloc(%d) failed\", (int) (combined_allocated * sizeof(struct reg *)));"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"a1d93be7_2056ffdb","line":2266,"in_reply_to":"58357896_57e29adf","updated":"2021-09-07 18:15:32.000000000","message":"Done. Then further down I cast it to an int again, because combined_list_size is an int*. I took a look at changing that to unsigned int, but that\u0027s a change that ripples all the way through into every target which implements get_gdb_reg_list.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"86eb00d5c90c9f80ade844ecea22088a10d4c28c","unresolved":true,"context_lines":[{"line_number":2266,"context_line":"\tint combined_allocated \u003d 256;"},{"line_number":2267,"context_line":"\t*combined_list \u003d malloc(combined_allocated * sizeof(struct reg *));"},{"line_number":2268,"context_line":"\tif (*combined_list \u003d\u003d NULL) {"},{"line_number":2269,"context_line":"\t\tLOG_ERROR(\"malloc(%d) failed\", (int) (combined_allocated * sizeof(struct reg *)));"},{"line_number":2270,"context_line":"\t\treturn ERROR_FAIL;"},{"line_number":2271,"context_line":"\t}"},{"line_number":2272,"context_line":"\t*combined_list_size \u003d 0;"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"8383330d_78195356","line":2269,"updated":"2021-09-05 20:55:51.000000000","message":"sizeof() returns a size_t value.\nWith combined_allocated changed to unsigned int, the result is size_t.\nRemove the cast to int and change %d to %zu.","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"dd90fb24fe96043dc4e5062834ce0125d6c4bf97","unresolved":false,"context_lines":[{"line_number":2266,"context_line":"\tint combined_allocated \u003d 256;"},{"line_number":2267,"context_line":"\t*combined_list \u003d malloc(combined_allocated * sizeof(struct reg *));"},{"line_number":2268,"context_line":"\tif (*combined_list \u003d\u003d NULL) {"},{"line_number":2269,"context_line":"\t\tLOG_ERROR(\"malloc(%d) failed\", (int) (combined_allocated * sizeof(struct reg *)));"},{"line_number":2270,"context_line":"\t\treturn ERROR_FAIL;"},{"line_number":2271,"context_line":"\t}"},{"line_number":2272,"context_line":"\t*combined_list_size \u003d 0;"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"2b919e39_49890ed6","line":2269,"in_reply_to":"8383330d_78195356","updated":"2021-09-07 18:15:32.000000000","message":"Done","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"86eb00d5c90c9f80ade844ecea22088a10d4c28c","unresolved":true,"context_lines":[{"line_number":2308,"context_line":"\t\t\t\t\t\tcombined_allocated *\u003d 2;"},{"line_number":2309,"context_line":"\t\t\t\t\t\t*combined_list \u003d realloc(*combined_list, combined_allocated * sizeof(struct reg *));"},{"line_number":2310,"context_line":"\t\t\t\t\t\tif (*combined_list \u003d\u003d NULL) {"},{"line_number":2311,"context_line":"\t\t\t\t\t\t\tLOG_ERROR(\"realloc(%d) failed\", (int) (combined_allocated * sizeof(struct reg *)));"},{"line_number":2312,"context_line":"\t\t\t\t\t\t\treturn ERROR_FAIL;"},{"line_number":2313,"context_line":"\t\t\t\t\t\t}"},{"line_number":2314,"context_line":"\t\t\t\t\t}"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"5a63adac_894fdcfd","line":2311,"updated":"2021-09-05 20:55:51.000000000","message":"same here","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"},{"author":{"_account_id":1001242,"name":"Tim Newsome","email":"tim@sifive.com","username":"timsifive"},"change_message_id":"dd90fb24fe96043dc4e5062834ce0125d6c4bf97","unresolved":false,"context_lines":[{"line_number":2308,"context_line":"\t\t\t\t\t\tcombined_allocated *\u003d 2;"},{"line_number":2309,"context_line":"\t\t\t\t\t\t*combined_list \u003d realloc(*combined_list, combined_allocated * sizeof(struct reg *));"},{"line_number":2310,"context_line":"\t\t\t\t\t\tif (*combined_list \u003d\u003d NULL) {"},{"line_number":2311,"context_line":"\t\t\t\t\t\t\tLOG_ERROR(\"realloc(%d) failed\", (int) (combined_allocated * sizeof(struct reg *)));"},{"line_number":2312,"context_line":"\t\t\t\t\t\t\treturn ERROR_FAIL;"},{"line_number":2313,"context_line":"\t\t\t\t\t\t}"},{"line_number":2314,"context_line":"\t\t\t\t\t}"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"465668d2_c50dcfaf","line":2311,"in_reply_to":"5a63adac_894fdcfd","updated":"2021-09-07 18:15:32.000000000","message":"Done","commit_id":"f63a4b1b790058aa494389df8a3baebae30c38ab"}]}