)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1001043,"name":"Chris Bertrand","email":"fenugrec@users.sourceforge.net","username":"fenugrec"},"change_message_id":"918a1d9040782d6eaecee3c235eafe339c4bd91f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"76e28c4b_daf1c781","updated":"2022-12-11 16:11:12.000000000","message":"I think your patch is an improvement, but I don\u0027t think it\u0027s quite the right fix.\n\nTrying to debug openocd while debugging a target proved difficult, but I think I may have found the root cause:\n\n```\nThread 1 \"openocd\" hit Breakpoint 2, write_gmon (duration_ms\u003d0x1fd, target\u003d0x555555a1dea0, end_address\u003d\u003coptimized out\u003e, start_address\u003d\u003coptimized out\u003e, with_range\u003d\u003coptimized out\u003e, filename\u003d\u003coptimized out\u003e, sample_num\u003d0x2710, samples\u003d0x555555a7ace0) at src/target/target.c:4258\n4258    in src/target/target.c\n1: max \u003d 0xfffffff9\n```\n\n0xfffffff9 is a magic value for returning from ISRs, or something to that effect. No idea how this should be handled.\n\n","commit_id":"c52e71d32ce00377d56872a3da2fad362165cda9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"751155fd4366ee10ed7572b1b39c138ece7ee653","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0c3aca76_428cb947","updated":"2022-12-14 10:13:41.000000000","message":"Thanks for testing, I will merge it shortly","commit_id":"c52e71d32ce00377d56872a3da2fad362165cda9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"bd15ef3d641adc536e60018f157e6c337ba1395d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d21dd55a_539f00f9","updated":"2022-12-14 15:48:11.000000000","message":"just to log here that for aarch64 gprof, the fields that contain min and max PC have to be 64 bits wide in the gmon file.","commit_id":"c52e71d32ce00377d56872a3da2fad362165cda9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"3948510e4ff9ef18adfe888c0d5a78103963c4c6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8994dbc8_70668216","in_reply_to":"76e28c4b_daf1c781","updated":"2022-12-11 16:46:49.000000000","message":"Thanks for the debug research.\nYes, 0xfffffff9 is a special value that ARM put in lr to indicate a return from ISR, but the pc should never get that value! It\u0027s odd that sampling the pc you could get it.\nAnyway, this patch should be able to work with that unusual pc value.\nIn the ticket you report that it\u0027s still failing.\nWhat about adding a print of min and max before the assert to catch why address_space \u003c 2?","commit_id":"c52e71d32ce00377d56872a3da2fad362165cda9"},{"author":{"_account_id":1001043,"name":"Chris Bertrand","email":"fenugrec@users.sourceforge.net","username":"fenugrec"},"change_message_id":"08f943411eed59069d9da7815decad3e6011dda2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b7c55dec_ab4cb39a","in_reply_to":"8994dbc8_70668216","updated":"2022-12-13 21:55:42.000000000","message":"My bad, I had been trying a different target which ends up in an empty `while (1);` loop, which meant  (max - min) \u003c 2 .\n\nOn the correct target device, I don\u0027t see an assert failure anymore. But still seeing that value; just added LOG_INFO(\"max %X, min %X\", max, min);\n\n`Info : max FFFFFFF9, min 800017C`\n\nI guess I\u0027ll have to start manually entering start and end params (disgusting), because this wide span will probably throw off the analysis ?\n\nSo this patch is OK, albeit a partial fix (as you stated, reporting proper errors may be a larger undertaking)","commit_id":"c52e71d32ce00377d56872a3da2fad362165cda9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"751155fd4366ee10ed7572b1b39c138ece7ee653","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cf98ef46_7cb88610","in_reply_to":"b7c55dec_ab4cb39a","updated":"2022-12-14 10:13:41.000000000","message":"\u003e My bad, I had been trying a different target which ends up in an empty `while (1);` loop, which meant  (max - min) \u003c 2 .\n\nAgree that the case \u0027while (1);\u0027 still triggers the assert.\nI will try to fix in a following small change as this only fixes the unsigned computation, plus I don;t want to introduce big changes during code freeze.\n\n\u003e On the correct target device, I don\u0027t see an assert failure anymore. But still seeing that value; just added LOG_INFO(\"max %X, min %X\", max, min);\n\u003e \n\u003e `Info : max FFFFFFF9, min 800017C`\n\u003e \n\u003e I guess I\u0027ll have to start manually entering start and end params (disgusting), because this wide span will probably throw off the analysis ?\n\nYes, the range will be required to focus the analysis when there is such huge gap between min and max.","commit_id":"c52e71d32ce00377d56872a3da2fad362165cda9"}]}