)]}'
{"id":"binutils-gdb~6187","triplet_id":"binutils-gdb~master~I2158d5732fc7d7ca06b0eb01f88cf27bf527b990","project":"binutils-gdb","branch":"master","attention_set":{},"removed_from_attention_set":{"1000001":{"account":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"last_update":"2021-12-09 02:21:45.000000000","reason":"Change was submitted"}},"hashtags":[],"change_id":"I2158d5732fc7d7ca06b0eb01f88cf27bf527b990","subject":"gdbserver: hide fork child threads from GDB","status":"MERGED","created":"2021-07-16 04:10:04.000000000","updated":"2021-12-09 02:21:45.000000000","submitted":"2021-12-09 02:21:45.000000000","submitter":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"total_comment_count":0,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"6187","meta_rev_id":"bf081c5599a4eab6150b5a88bebd3505a324c7dc","_number":6187,"virtual_id_number":6187,"owner":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"actions":{},"labels":{"Code-Review":{"all":[{"value":0,"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},{"value":0,"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]}],"values":{"-2":"This shall not be merged","-1":"I would prefer this is not merged as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"description":"","default_value":0,"optional":true},"Verified":{"all":[{"value":0,"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},{"value":0,"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]}],"values":{"-2":"Failure","-1":"Not built"," 0":"No score","+1":"Unstable","+2":"Success"},"description":"CI Build results","default_value":0,"optional":true},"CI-Build":{"all":[{"value":0,"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},{"value":0,"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]}],"values":{" 0":"No score","+1":"Trigger a CI build"},"description":"Trigger CI builds","default_value":0,"optional":true},"Smoke-Build-Lvl1":{"all":[{"value":0,"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},{"value":0,"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]}],"values":{" 0":"No score","+1":"Trigger a level 1 smoke build"},"description":"Trigger Level 1 Smoke builds","default_value":0,"optional":true},"Smoke-Build-Lvl2":{"all":[{"value":0,"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},{"value":0,"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]}],"values":{" 0":"No score","+1":"Trigger a level 2 smoke build"},"description":"Trigger Level 2 Smoke builds","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2021-11-13 02:09:12.000000000","updated_by":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"reviewer":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"state":"CC"},{"updated":"2021-11-13 02:43:31.000000000","updated_by":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"reviewer":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"state":"REVIEWER"}],"messages":[{"id":"4084c96829a24b6fa5a02264af4c8e32c55760cd","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-07-16 04:10:04.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"003df86f95f6185c736e79a7e28f07d3cd2a1957","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-07-24 04:41:14.000000000","message":"Uploaded patch set 2: Patch Set 1 was rebased.","accounts_in_message":[],"_revision_number":2},{"id":"a7d44ef10b9223f749f1381b5a30dba53b2109b9","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-07-25 02:38:21.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"6eb7ca7c094232f8bee084c44e23c0f5478fc72f","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-07-26 03:56:40.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"38b400e3cb9feae876fd17b873c0f5e15c414939","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-07-27 01:04:34.000000000","message":"Uploaded patch set 5: Patch Set 4 was rebased.","accounts_in_message":[],"_revision_number":5},{"id":"8def1d7f20e554ef47b11d1c223a8754b2eaa34b","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-08-19 03:21:32.000000000","message":"Uploaded patch set 6.","accounts_in_message":[],"_revision_number":6},{"id":"8c7469733cba40291ff9931db750614950685306","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-28 02:27:52.000000000","message":"Uploaded patch set 7.","accounts_in_message":[],"_revision_number":7},{"id":"574826666c85ddcd0340ac992ccc3600e472e172","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-28 04:17:05.000000000","message":"Uploaded patch set 8: Patch Set 7 was rebased.","accounts_in_message":[],"_revision_number":8},{"id":"79c17cd710877260937317db255f76a35bdbaf2c","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-28 21:31:23.000000000","message":"Uploaded patch set 9.","accounts_in_message":[],"_revision_number":9},{"id":"e1b69612ce339901f1889237609b021bba6abff4","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-29 03:14:48.000000000","message":"Uploaded patch set 10: Patch Set 9 was rebased.","accounts_in_message":[],"_revision_number":10},{"id":"bf34c377c748c340e5dc96260a4afd3cbeb9d6b3","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-29 03:30:32.000000000","message":"Uploaded patch set 11: Patch Set 10 was rebased.","accounts_in_message":[],"_revision_number":11},{"id":"689f08d1316ff647d147134206ac7c5c2bef98ef","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-29 04:03:45.000000000","message":"Uploaded patch set 12: Patch Set 11 was rebased.","accounts_in_message":[],"_revision_number":12},{"id":"a5244ad89a600efcf34a146c5e3bc9354b39f62f","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-29 13:43:38.000000000","message":"Uploaded patch set 13: Patch Set 12 was rebased.","accounts_in_message":[],"_revision_number":13},{"id":"9b75aa27f3e6f1117b9df98318fb9bf8a2186a2b","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-29 21:30:19.000000000","message":"Uploaded patch set 14: Patch Set 13 was rebased.","accounts_in_message":[],"_revision_number":14},{"id":"8077a63a2ad1e1656ec2096eeb7b82051a8c0771","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-30 01:06:27.000000000","message":"Uploaded patch set 15: Patch Set 14 was rebased.","accounts_in_message":[],"_revision_number":15},{"id":"e7961b4a27ecd13df818d1a68c245596555c6a9e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-30 01:27:13.000000000","message":"Uploaded patch set 16: New patch set was added with same tree, parent, and commit message as Patch Set 15.","accounts_in_message":[],"_revision_number":16},{"id":"0f1feac790cd24b22474f6b9ed8ac81a5d6161e6","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-09-30 02:31:55.000000000","message":"Uploaded patch set 17: Patch Set 16 was rebased.","accounts_in_message":[],"_revision_number":17},{"id":"1d580d6a60484edc9edd7750aba0c8eba405915f","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-14 14:42:23.000000000","message":"Uploaded patch set 18: Patch Set 17 was rebased.","accounts_in_message":[],"_revision_number":18},{"id":"7545a589deca49320addfa6a7d74ccd114618dfc","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-14 19:55:47.000000000","message":"Uploaded patch set 19.","accounts_in_message":[],"_revision_number":19},{"id":"d1284601e0defbdf9d8fc9bf22646c59a5632c25","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-18 21:08:53.000000000","message":"Uploaded patch set 20.","accounts_in_message":[],"_revision_number":20},{"id":"2d5ad5466d595e2e262db9e99f3eb23e82f44f31","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-19 20:15:24.000000000","message":"Uploaded patch set 21: Patch Set 20 was rebased.","accounts_in_message":[],"_revision_number":21},{"id":"f006a9265ea514537f3b406253b59b05cb1ad9b0","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-20 14:59:00.000000000","message":"Uploaded patch set 22: Patch Set 21 was rebased.","accounts_in_message":[],"_revision_number":22},{"id":"cbe5d44c5e5aae2d546e6464965782feff6ffbd1","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-20 21:28:05.000000000","message":"Uploaded patch set 23: Patch Set 22 was rebased.","accounts_in_message":[],"_revision_number":23},{"id":"c94dd229b294ac63673d1f16649e7b12b0c2a774","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-21 02:51:34.000000000","message":"Uploaded patch set 24: Patch Set 23 was rebased.","accounts_in_message":[],"_revision_number":24},{"id":"3a810c4bb323ac9099e8cc55222a5586c33ffd89","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-21 17:42:56.000000000","message":"Uploaded patch set 25: Patch Set 24 was rebased.","accounts_in_message":[],"_revision_number":25},{"id":"928b8eaa040913cf667817505b0b8fabe875df60","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-21 20:08:14.000000000","message":"Uploaded patch set 26.","accounts_in_message":[],"_revision_number":26},{"id":"b875ada2eb9a0a715144dcc715ae47d76e2ee4d0","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-21 20:17:09.000000000","message":"Uploaded patch set 27: Patch Set 26 was rebased.","accounts_in_message":[],"_revision_number":27},{"id":"9e29a4b98744a4978ddf552b7f1fe9c768387c67","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-25 14:18:42.000000000","message":"Uploaded patch set 28: Patch Set 27 was rebased.","accounts_in_message":[],"_revision_number":28},{"id":"c9d5f99bb6c8c5afccf1075b861e6c464316c22d","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-25 14:23:26.000000000","message":"Uploaded patch set 29: New patch set was added with same tree, parent, and commit message as Patch Set 28.","accounts_in_message":[],"_revision_number":29},{"id":"bac1c5ef807f7c8ef9c51ea16f6baf13e6cff453","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-25 18:32:07.000000000","message":"Uploaded patch set 30: Patch Set 29 was rebased.","accounts_in_message":[],"_revision_number":30},{"id":"1e3d3c68703a773e94bf302c2549ae472a81c343","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-25 21:14:31.000000000","message":"Uploaded patch set 31: Patch Set 30 was rebased.","accounts_in_message":[],"_revision_number":31},{"id":"084dda518e6597daa03a1dcc3ffab47b72a90760","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-26 18:24:55.000000000","message":"Uploaded patch set 32: Patch Set 31 was rebased.","accounts_in_message":[],"_revision_number":32},{"id":"24815ffbb8e04a18551d1b691e98a6e473404321","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-28 05:43:11.000000000","message":"Uploaded patch set 33: Patch Set 32 was rebased.","accounts_in_message":[],"_revision_number":33},{"id":"c6abd2e2f60b2cb1b05c43be1005bf7e453cd575","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-28 16:47:33.000000000","message":"Uploaded patch set 34.","accounts_in_message":[],"_revision_number":34},{"id":"8aedb231731e6a0649c572d89d77ae824e32b47e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-28 19:49:43.000000000","message":"Uploaded patch set 35: Patch Set 34 was rebased.","accounts_in_message":[],"_revision_number":35},{"id":"8d0fd6e1d2b91f36320f2ac0efe34cbd7aa22f07","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-28 21:11:03.000000000","message":"Uploaded patch set 36: Patch Set 35 was rebased.","accounts_in_message":[],"_revision_number":36},{"id":"e5ce704634febdb8e265b88e21a5d1def31739a9","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-29 02:38:41.000000000","message":"Uploaded patch set 37: Patch Set 36 was rebased.","accounts_in_message":[],"_revision_number":37},{"id":"1a3843532e41d9fc6d035a5a1a6ec5b29edce2d2","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-29 12:56:48.000000000","message":"Uploaded patch set 38: Patch Set 37 was rebased.","accounts_in_message":[],"_revision_number":38},{"id":"125c3d4d6537d03b9885e7d0ddd59c930191ab67","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-10-29 20:33:24.000000000","message":"Uploaded patch set 39.","accounts_in_message":[],"_revision_number":39},{"id":"fe6198229fdd589c4a5d8e94bc3f8a24c02a9435","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-12 20:59:30.000000000","message":"Uploaded patch set 40: Patch Set 39 was rebased.","accounts_in_message":[],"_revision_number":40},{"id":"cfb3f937edea61781ac903c66efc6702102b068e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-13 02:08:18.000000000","message":"Patch Set 41: Patch Set 40 was rebased","accounts_in_message":[],"_revision_number":41},{"id":"4577ac6825c06aad1b833a85148283cb30263616","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-13 02:09:05.000000000","message":"Patch Set 41: CI-Build+1","accounts_in_message":[],"_revision_number":41},{"id":"67cb7095c98e24a92f18441b4c130697f80865d3","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-13 02:09:12.000000000","message":"Patch Set 41:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/76/","accounts_in_message":[],"_revision_number":41},{"id":"250b71bff4a0e44226bcbf2812ad0c01aadd8c23","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-13 02:43:31.000000000","message":"Patch Set 41: Verified-2\n\nBuild Failed \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/76/ : FAILURE","accounts_in_message":[],"_revision_number":41},{"id":"7098b5b41baba190a44b745e9be9d21ca78a416a","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-14 13:29:51.000000000","message":"Uploaded patch set 42: Patch Set 41 was rebased.","accounts_in_message":[],"_revision_number":42},{"id":"3d59d5724fe1bfacf373184d317c2dcffac935f9","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-14 17:01:44.000000000","message":"Patch Set 42: CI-Build+1","accounts_in_message":[],"_revision_number":42},{"id":"43867725c9510648b670b7c478258c6d6677c3f9","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-14 17:01:52.000000000","message":"Patch Set 42:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/79/","accounts_in_message":[],"_revision_number":42},{"id":"1d306974b61b7dac1d48a8c173db1daecf4c4c7a","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-14 17:32:13.000000000","message":"Patch Set 42: Verified+2\n\nBuild Successful \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/79/ : SUCCESS","accounts_in_message":[],"_revision_number":42},{"id":"f4ab9232e93ec0a59cabe8697394a893a8000798","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-16 18:35:13.000000000","message":"Uploaded patch set 43: Patch Set 42 was rebased.","accounts_in_message":[],"_revision_number":43},{"id":"d1fe680d737cf14898dd30f9e699a20216e4577c","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-16 18:35:37.000000000","message":"Patch Set 43: CI-Build+1","accounts_in_message":[],"_revision_number":43},{"id":"c42b7a20a1bb6f98d84b887a394cfa519ef03581","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-16 18:35:47.000000000","message":"Patch Set 43:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/86/","accounts_in_message":[],"_revision_number":43},{"id":"3e2530606cb4a71061dd73c42e8f3ea25d44a655","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-16 19:06:01.000000000","message":"Patch Set 43: Verified+2\n\nBuild Successful \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/86/ : SUCCESS","accounts_in_message":[],"_revision_number":43},{"id":"514d5c19c2d2ea65f81d9cf91b1de5aaa3adcf5e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-16 21:26:39.000000000","message":"Uploaded patch set 44: Patch Set 43 was rebased.","accounts_in_message":[],"_revision_number":44},{"id":"82a000956c43da3f80a7d56c2e7ed2e4f83a1958","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-16 21:26:56.000000000","message":"Patch Set 44: CI-Build+1","accounts_in_message":[],"_revision_number":44},{"id":"5e9b31dcf873c273d2a2b88bfeff8305f90c4915","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-16 21:27:02.000000000","message":"Patch Set 44:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/87/","accounts_in_message":[],"_revision_number":44},{"id":"1fb99879ef26d32682130616c0e0288d065241cf","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-16 21:54:23.000000000","message":"Patch Set 44: Verified+2\n\nBuild Successful \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/87/ : SUCCESS","accounts_in_message":[],"_revision_number":44},{"id":"7ffb280266d0071194dc13bfe61f90160f505adb","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-17 20:57:12.000000000","message":"Uploaded patch set 45: Patch Set 44 was rebased.","accounts_in_message":[],"_revision_number":45},{"id":"3d2fe673b6c4aeb880a58fb070b9d3a268df2546","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-18 20:08:21.000000000","message":"Uploaded patch set 46: Patch Set 45 was rebased.","accounts_in_message":[],"_revision_number":46},{"id":"5987c88b009d731c680519b4fee5c20cf4896adf","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-22 16:26:33.000000000","message":"Uploaded patch set 47: Patch Set 46 was rebased.","accounts_in_message":[],"_revision_number":47},{"id":"2dc85de052770c0afb6f1d5e4aaa1c763bbbc8f9","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-22 20:11:02.000000000","message":"Uploaded patch set 48: New patch set was added with same tree, parent, and commit message as Patch Set 47.","accounts_in_message":[],"_revision_number":48},{"id":"029ec3d1f4a965e513b9a40f19475ba323cd62cd","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-23 03:43:41.000000000","message":"Uploaded patch set 49: Patch Set 48 was rebased.","accounts_in_message":[],"_revision_number":49},{"id":"94af6c116ea35056c408429e93a830fb4762ee03","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-24 19:58:31.000000000","message":"Uploaded patch set 50: Patch Set 49 was rebased.","accounts_in_message":[],"_revision_number":50},{"id":"bc5dcf355e3730648906f908e633d96116dc2e25","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-24 19:59:10.000000000","message":"Patch Set 50: CI-Build+1","accounts_in_message":[],"_revision_number":50},{"id":"d3aa361d4c75dcc5a6c6298c9b6e622f198bc9b8","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-24 19:59:17.000000000","message":"Patch Set 50:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/133/","accounts_in_message":[],"_revision_number":50},{"id":"3ec7133e6b8e2ce912a563b32ea18fe8de79c172","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-24 20:28:25.000000000","message":"Patch Set 50: Verified+2\n\nBuild Successful \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/133/ : SUCCESS","accounts_in_message":[],"_revision_number":50},{"id":"5d88a1f924bf41ec94de1d3e0a675494a2032c15","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-27 04:15:57.000000000","message":"Uploaded patch set 51.","accounts_in_message":[],"_revision_number":51},{"id":"b5a80968aa5720811e510c9ebea0201bb21c5425","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-27 04:16:07.000000000","message":"Patch Set 51:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/136/","accounts_in_message":[],"_revision_number":51},{"id":"961dc08a8e9f2789f2685a14291d4609883056f2","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-27 04:44:50.000000000","message":"Patch Set 51: Verified-2\n\nBuild Failed \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/136/ : FAILURE","accounts_in_message":[],"_revision_number":51},{"id":"2f7576eb1bb4863a0e9b648d2e5baa98234d9645","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-27 15:12:11.000000000","message":"Uploaded patch set 52: Patch Set 51 was rebased.","accounts_in_message":[],"_revision_number":52},{"id":"a2f4eb552dc282b4d81d887869b14d654e9b6158","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-28 13:10:04.000000000","message":"Uploaded patch set 53: CI-Build+1: Patch Set 52 was rebased.","accounts_in_message":[],"_revision_number":53},{"id":"b43075367f7c7bff4df9c7d9eed694a9004cf4df","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-28 13:10:12.000000000","message":"Patch Set 53:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/142/","accounts_in_message":[],"_revision_number":53},{"id":"6bce58b68800e39af2571b7b3ac12196871e80fa","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-11-28 13:38:49.000000000","message":"Patch Set 53: Verified+2\n\nBuild Successful \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/142/ : SUCCESS","accounts_in_message":[],"_revision_number":53},{"id":"9fb73559e4fb25ea8945aaa0acb2e853bb6a5a9d","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-29 14:27:30.000000000","message":"Uploaded patch set 54.","accounts_in_message":[],"_revision_number":54},{"id":"0e853c986bf8540c8464f67262a408ee90e6f8c5","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-30 19:12:46.000000000","message":"Uploaded patch set 55.","accounts_in_message":[],"_revision_number":55},{"id":"f90ca764e80efbd40b4408a1ebec6be0a4efe1a3","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-11-30 19:26:55.000000000","message":"Uploaded patch set 56: Patch Set 55 was rebased.","accounts_in_message":[],"_revision_number":56},{"id":"84a67ec93596ace377442643465a7dc5f7c6de7a","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-01 00:58:48.000000000","message":"Uploaded patch set 57: Patch Set 56 was rebased.","accounts_in_message":[],"_revision_number":57},{"id":"a165ed49b6973ad0efe9d2195f15865fb30377ae","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-01 02:16:55.000000000","message":"Uploaded patch set 58: Patch Set 57 was rebased.","accounts_in_message":[],"_revision_number":58},{"id":"23f0dd93a67a3a3dec3da2edb107df4f322775ab","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-01 02:50:52.000000000","message":"Uploaded patch set 59: New patch set was added with same tree, parent, and commit message as Patch Set 58.","accounts_in_message":[],"_revision_number":59},{"id":"25e88400d15ff7446d73b11db54d470f48d50a08","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-01 04:12:45.000000000","message":"Patch Set 59: CI-Build+1","accounts_in_message":[],"_revision_number":59},{"id":"5065a165fb4451f141b028a78b9de3fc8b8e29f1","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-12-01 04:12:51.000000000","message":"Patch Set 59:\n\nBuild Started https://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/11/","accounts_in_message":[],"_revision_number":59},{"id":"382ec4b1c9dcdb6619dbe8ec8fe1b67358dbe3f9","tag":"autogenerated:jenkins-gerrit-trigger","author":{"_account_id":1000002,"name":"jenkins","email":"jenkins@lttng.org","username":"jenkins","avatars":[{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/e3f1da3d4191917309975c0380f40764.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}],"tags":["SERVICE_USER"]},"date":"2021-12-01 06:44:06.000000000","message":"Patch Set 59: Verified-2\n\nBuild Failed \n\nhttps://ci.lttng.org/job/dev_gerrit_binutils-gdb_build/11/ : FAILURE","accounts_in_message":[],"_revision_number":59},{"id":"cf827d725d1fae7d9799a9834c5d35f06ee7d171","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-01 14:23:53.000000000","message":"Uploaded patch set 60: Patch Set 59 was rebased.","accounts_in_message":[],"_revision_number":60},{"id":"21a1c7108dbb57fc5d0ec887715bf6fd12b38c78","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-01 15:30:57.000000000","message":"Uploaded patch set 61.","accounts_in_message":[],"_revision_number":61},{"id":"cfd65e10f109de45450543f7761fc4676588efb0","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-04 03:35:51.000000000","message":"Uploaded patch set 62: Patch Set 61 was rebased.","accounts_in_message":[],"_revision_number":62},{"id":"67866d1beac3497cbf1389f6ed05ece306f760db","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-09 02:01:00.000000000","message":"Uploaded patch set 63: Patch Set 62 was rebased.","accounts_in_message":[],"_revision_number":63},{"id":"bf081c5599a4eab6150b5a88bebd3505a324c7dc","tag":"autogenerated:gerrit:merged","author":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"date":"2021-12-09 02:21:45.000000000","message":"Change has been successfully pushed.","accounts_in_message":[],"_revision_number":63}],"current_revision_number":63,"current_revision":"7b961964f86618773218c067bfff066b2bff8328","revisions":{"efe5c4246673e6e107f3729d53fd909361e0e3db":{"kind":"REWORK","_number":1,"created":"2021-07-16 04:10:04.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/1","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/1","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/1 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/1","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d8f9969cb1829ab0992e5748ebf54d241610e137","subject":"gdb: nat/x86-dregs.c: add and use x86_dr_low_can_get_status","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd8f9969cb1829ab0992e5748ebf54d241610e137"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:58.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003defe5c4246673e6e107f3729d53fd909361e0e3db"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003defe5c4246673e6e107f3729d53fd909361e0e3db"}]},"branch":"refs/heads/master"},"928f516a5e62ae6df711b2087ea5f25dab771b2c":{"kind":"TRIVIAL_REBASE","_number":2,"created":"2021-07-24 04:41:14.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/2","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/2","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/2 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/2","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"77db4723ddda2a5eb20876e8a818f77ffa7dafc8","subject":"Update the NetBSD system call table to match NetBSD-current.","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d77db4723ddda2a5eb20876e8a818f77ffa7dafc8"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-24 02:33:59.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d928f516a5e62ae6df711b2087ea5f25dab771b2c"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d928f516a5e62ae6df711b2087ea5f25dab771b2c"}]},"branch":"refs/heads/master"},"0ddbf67cd10a47e4734ea858452c061e1269134f":{"kind":"REWORK","_number":3,"created":"2021-07-25 02:38:21.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/3","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/3","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/3 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/3","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"60a5fb48d1b49bf567509a748d71a75b38db2ab7","subject":"Automatic date update in version.in","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d60a5fb48d1b49bf567509a748d71a75b38db2ab7"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-25 02:38:17.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0ddbf67cd10a47e4734ea858452c061e1269134f"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0ddbf67cd10a47e4734ea858452c061e1269134f"}]},"branch":"refs/heads/master"},"8164475035afe859630c31d0fc04e1c7407d72f5":{"kind":"REWORK","_number":4,"created":"2021-07-26 03:56:40.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/4","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/4","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/4 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/4","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"b924d9bad57a1ddb2e0f83229db5a33b5fb7bec6","subject":"Automatic date update in version.in","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003db924d9bad57a1ddb2e0f83229db5a33b5fb7bec6"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-26 03:56:00.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d8164475035afe859630c31d0fc04e1c7407d72f5"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d8164475035afe859630c31d0fc04e1c7407d72f5"}]},"branch":"refs/heads/master"},"13e02952f3def0a23ef3e9cb009f78cd9518bcce":{"kind":"TRIVIAL_REBASE","_number":5,"created":"2021-07-27 01:04:34.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/5","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/5","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/5 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/5","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"dfe3b80549206d364eb607a5ba62c2b86d421115","subject":"Fix ld test case that assumes --enable-textrel-check","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003ddfe3b80549206d364eb607a5ba62c2b86d421115"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-27 01:01:15.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d13e02952f3def0a23ef3e9cb009f78cd9518bcce"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d13e02952f3def0a23ef3e9cb009f78cd9518bcce"}]},"branch":"refs/heads/master"},"3accea37929ca3e3c5d5eb3df5548ca9f1787678":{"kind":"REWORK","_number":6,"created":"2021-08-19 03:21:32.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/6","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/6","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/6 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/6","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"533f04079c7de9a56f3c463ff1669d2c9eb5a576","subject":"[gdb] [rs6000] Add ppc64_linux_gcc_target_options method.","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d533f04079c7de9a56f3c463ff1669d2c9eb5a576"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-08-19 03:20:52.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when we step a thread and another forks at the same time.  The\nbug looks like (if I reproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls for the \"single step complete\n   SIGTRAP\" and the \"fork\" events from the kernel.  It arbitrarily\n   choses one event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet.  See remove_new_fork_children in remote.c.  In our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  I think we\nneed to implement the same kind of logic GDBserver-side: if there\u0027s a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nSo, implementation details-wise, the fix for this is all in GDBserver.\nThe Linux layer already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child.  That simplifies things a bit in linux_set_resume_request.\nCurrently, when lwp-\u003efork_relative is set, we have to deduce whether\nthis is a parent or child using the pending event.  With separate\nfork_parent and fork_child fields, it becomes more obvious.  If the\nthread has a fork parent, then it means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3accea37929ca3e3c5d5eb3df5548ca9f1787678"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3accea37929ca3e3c5d5eb3df5548ca9f1787678"}]},"branch":"refs/heads/master"},"978da2104ed1449cf0b8da988659c9ed60ad3f83":{"kind":"REWORK","_number":7,"created":"2021-09-28 02:27:52.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/7","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/7","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/7 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/7","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/7 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"da474da158e09787f2a36f480bfa1b79160a0e91","subject":"gdb: don\u0027t share aspace/pspace on fork with \"detach-on-fork on\" and \"follow-fork-mode child\"","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dda474da158e09787f2a36f480bfa1b79160a0e91"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-27 21:48:20.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d978da2104ed1449cf0b8da988659c9ed60ad3f83"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d978da2104ed1449cf0b8da988659c9ed60ad3f83"}]},"branch":"refs/heads/master"},"9602003c1fb34846d59826982333df803da3b874":{"kind":"TRIVIAL_REBASE","_number":8,"created":"2021-09-28 04:17:05.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/8","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/8","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/8 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/8","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/8 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"2c02075a8ec5223bc4cbcc9561eb91e28d46a9e5","subject":"x86: Print {bad} on invalid broadcast in OP_E_memory","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d2c02075a8ec5223bc4cbcc9561eb91e28d46a9e5"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-07-16 04:09:25.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 04:08:35.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9602003c1fb34846d59826982333df803da3b874"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9602003c1fb34846d59826982333df803da3b874"}]},"branch":"refs/heads/master"},"1526590c97cf0effb5b43df0bcc76e606a7cef85":{"kind":"REWORK","_number":9,"created":"2021-09-28 21:31:23.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/9","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/9","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/9 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/9","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/9 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"bcc6099923935929cdd69e640a2e254adec17458","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dbcc6099923935929cdd69e640a2e254adec17458"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 21:30:57.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1526590c97cf0effb5b43df0bcc76e606a7cef85"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1526590c97cf0effb5b43df0bcc76e606a7cef85"}]},"branch":"refs/heads/master"},"aebf05cd48784f7ca0b9edd9b3da434e2818e848":{"kind":"TRIVIAL_REBASE","_number":10,"created":"2021-09-29 03:14:48.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/10","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/10","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/10 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/10","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/10 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"0ad3fc1f46fab0513703818788690fe4e304e17e","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0ad3fc1f46fab0513703818788690fe4e304e17e"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-29 03:14:42.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003daebf05cd48784f7ca0b9edd9b3da434e2818e848"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003daebf05cd48784f7ca0b9edd9b3da434e2818e848"}]},"branch":"refs/heads/master"},"a10b7b250ffd3f011e1633fa900e5e31737bbc7e":{"kind":"TRIVIAL_REBASE","_number":11,"created":"2021-09-29 03:30:32.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/11","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/11","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/11 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/11","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/11 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"791338ce3945a93dacfa0d6d8519d8516f99be0a","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d791338ce3945a93dacfa0d6d8519d8516f99be0a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-29 03:30:28.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da10b7b250ffd3f011e1633fa900e5e31737bbc7e"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da10b7b250ffd3f011e1633fa900e5e31737bbc7e"}]},"branch":"refs/heads/master"},"b9cd79446bdb102a476bae5735d579bf58bf7fbe":{"kind":"TRIVIAL_REBASE","_number":12,"created":"2021-09-29 04:03:45.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/12","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/12","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/12 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/12","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/12 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"95585d476d7302d4e057dea2f2e360aa5723a26f","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d95585d476d7302d4e057dea2f2e360aa5723a26f"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-29 04:03:42.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003db9cd79446bdb102a476bae5735d579bf58bf7fbe"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003db9cd79446bdb102a476bae5735d579bf58bf7fbe"}]},"branch":"refs/heads/master"},"3daea79111387e9aae7c0059e065bb32f55f067f":{"kind":"TRIVIAL_REBASE","_number":13,"created":"2021-09-29 13:43:38.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/13","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/13","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/13 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/13","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/13 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cd3ea1236879a459accf7d93fbd332bcfe272462","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dcd3ea1236879a459accf7d93fbd332bcfe272462"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-29 13:43:34.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3daea79111387e9aae7c0059e065bb32f55f067f"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3daea79111387e9aae7c0059e065bb32f55f067f"}]},"branch":"refs/heads/master"},"d72a8a68472080b97b357b7092ee88f5f174fa7d":{"kind":"TRIVIAL_REBASE","_number":14,"created":"2021-09-29 21:30:19.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/14","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/14","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/14 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/14","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/14 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"92727d61135a2c0875194989b53753f1d7ab16f2","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d92727d61135a2c0875194989b53753f1d7ab16f2"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-29 21:29:42.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd72a8a68472080b97b357b7092ee88f5f174fa7d"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd72a8a68472080b97b357b7092ee88f5f174fa7d"}]},"branch":"refs/heads/master"},"f7f5f364b15379bf87fdf2506507865a03d3a96a":{"kind":"TRIVIAL_REBASE","_number":15,"created":"2021-09-30 01:06:27.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/15","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/15","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/15 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/15 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/15 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/15 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/15","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/15 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"7dd0cf324fdd785a7f0300914178c19f016b8a2b","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7dd0cf324fdd785a7f0300914178c19f016b8a2b"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-30 01:06:21.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003df7f5f364b15379bf87fdf2506507865a03d3a96a"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003df7f5f364b15379bf87fdf2506507865a03d3a96a"}]},"branch":"refs/heads/master"},"f5c84a2f94c743c0568abe21e7adcb1b3abd2a44":{"kind":"NO_CHANGE","_number":16,"created":"2021-09-30 01:27:13.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/16","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/16","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/16 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/16 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/16 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/16 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/16","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/16 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"23da95e50fc921c92a9f3c2e32fa49a915bf7d55","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d23da95e50fc921c92a9f3c2e32fa49a915bf7d55"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-30 01:25:53.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003df5c84a2f94c743c0568abe21e7adcb1b3abd2a44"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003df5c84a2f94c743c0568abe21e7adcb1b3abd2a44"}]},"branch":"refs/heads/master"},"344c7e970510f68c3001ede53197b465927b47a2":{"kind":"TRIVIAL_REBASE","_number":17,"created":"2021-09-30 02:31:55.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/17","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/17","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/17 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/17 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/17 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/17 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/17","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/17 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"9d2651e9769b424854a95169e7046657b51bce88","subject":"gdb, gdbserver: make target_waitstatus safe","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9d2651e9769b424854a95169e7046657b51bce88"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-30 02:31:51.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d344c7e970510f68c3001ede53197b465927b47a2"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d344c7e970510f68c3001ede53197b465927b47a2"}]},"branch":"refs/heads/master"},"a45293ccfa1296a01de140abce889ec6474221f8":{"kind":"TRIVIAL_REBASE","_number":18,"created":"2021-10-14 14:42:23.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/18","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/18","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/18 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/18 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/18 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/18 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/18","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/18 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"361e5e02c8ef7051f5468d6f85dab6c172b50a30","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d361e5e02c8ef7051f5468d6f85dab6c172b50a30"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-14 14:42:12.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da45293ccfa1296a01de140abce889ec6474221f8"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da45293ccfa1296a01de140abce889ec6474221f8"}]},"branch":"refs/heads/master"},"368938bcdf2ecac5d3f7761b19b870d70483dcc7":{"kind":"REWORK","_number":19,"created":"2021-10-14 19:55:47.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/19","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/19","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/19 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/19 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/19 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/19 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/19","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/19 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"68d8fd4c12071223410036b5615e73a01a64ac8f","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d68d8fd4c12071223410036b5615e73a01a64ac8f"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-14 19:55:27.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d368938bcdf2ecac5d3f7761b19b870d70483dcc7"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d368938bcdf2ecac5d3f7761b19b870d70483dcc7"}]},"branch":"refs/heads/master"},"614255c3dc216e06351fbd84ac439cc0328c24e6":{"kind":"REWORK","_number":20,"created":"2021-10-18 21:08:53.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/20","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/20","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/20 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/20 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/20 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/20 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/20","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/20 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3a05f1b94e0a8c4e0afa105b3ec2eb83ee9ed0bc","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3a05f1b94e0a8c4e0afa105b3ec2eb83ee9ed0bc"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-18 19:43:26.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d614255c3dc216e06351fbd84ac439cc0328c24e6"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d614255c3dc216e06351fbd84ac439cc0328c24e6"}]},"branch":"refs/heads/master"},"3293de409db6d5e73ee3497d4a5585e9fda0f6a4":{"kind":"TRIVIAL_REBASE","_number":21,"created":"2021-10-19 20:15:24.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/21","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/21","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/21 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/21 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/21 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/21 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/21","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/21 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"1abeb912b462d42b1e0d68c7f4d3f93bcd0d4a6d","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1abeb912b462d42b1e0d68c7f4d3f93bcd0d4a6d"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-19 20:15:11.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3293de409db6d5e73ee3497d4a5585e9fda0f6a4"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3293de409db6d5e73ee3497d4a5585e9fda0f6a4"}]},"branch":"refs/heads/master"},"839f6b8ca26c3b558d8b75fdceae34f200bff2ef":{"kind":"TRIVIAL_REBASE","_number":22,"created":"2021-10-20 14:59:00.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/22","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/22","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/22 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/22 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/22 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/22 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/22","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/22 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"93464b29f2d216b9c376b0afb6ff92d36ce1c26c","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d93464b29f2d216b9c376b0afb6ff92d36ce1c26c"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-20 00:32:57.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d839f6b8ca26c3b558d8b75fdceae34f200bff2ef"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d839f6b8ca26c3b558d8b75fdceae34f200bff2ef"}]},"branch":"refs/heads/master"},"82c0ad800e8a78c832b8ebf20f8a813ab79921a8":{"kind":"TRIVIAL_REBASE","_number":23,"created":"2021-10-20 21:28:05.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/23","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/23","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/23 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/23 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/23 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/23 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/23","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/23 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6e2edb89780855d25ec810160f88528f4f404790","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d6e2edb89780855d25ec810160f88528f4f404790"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-20 21:27:53.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d82c0ad800e8a78c832b8ebf20f8a813ab79921a8"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d82c0ad800e8a78c832b8ebf20f8a813ab79921a8"}]},"branch":"refs/heads/master"},"dee25bfcead154305946107f9e2670750f85de13":{"kind":"TRIVIAL_REBASE","_number":24,"created":"2021-10-21 02:51:34.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/24","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/24","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/24 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/24 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/24 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/24 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/24","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/24 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3ab488f996e1a976cf186230b1fb4d4fba7dc24d","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3ab488f996e1a976cf186230b1fb4d4fba7dc24d"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-21 02:51:24.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003ddee25bfcead154305946107f9e2670750f85de13"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003ddee25bfcead154305946107f9e2670750f85de13"}]},"branch":"refs/heads/master"},"7222db0f5a802eac65cc6238a6028f26b3aaa543":{"kind":"TRIVIAL_REBASE","_number":25,"created":"2021-10-21 17:42:56.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/25","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/25","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/25 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/25 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/25 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/25 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/25","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/25 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"08c94de46fd3568f9bdcd4d70e0bcbe30ea917c3","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d08c94de46fd3568f9bdcd4d70e0bcbe30ea917c3"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-21 17:42:51.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7222db0f5a802eac65cc6238a6028f26b3aaa543"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7222db0f5a802eac65cc6238a6028f26b3aaa543"}]},"branch":"refs/heads/master"},"8b0d6430b7f19d070a883ecb68156be3bc36a1d2":{"kind":"REWORK","_number":26,"created":"2021-10-21 20:08:14.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/26","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/26","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/26 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/26 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/26 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/26 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/26","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/26 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"a93f40ad5cb423f27854cdf41d5725d6a4c839c5","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da93f40ad5cb423f27854cdf41d5725d6a4c839c5"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-21 19:27:45.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d8b0d6430b7f19d070a883ecb68156be3bc36a1d2"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d8b0d6430b7f19d070a883ecb68156be3bc36a1d2"}]},"branch":"refs/heads/master"},"7668ac04dd5b3b6178b66fb2da08a02df0559a84":{"kind":"TRIVIAL_REBASE","_number":27,"created":"2021-10-21 20:17:09.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/27","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/27","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/27 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/27 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/27 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/27 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/27","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/27 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"4515a6fd1c2dd18e714a34e8132672d45d224610","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d4515a6fd1c2dd18e714a34e8132672d45d224610"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-21 20:17:01.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7668ac04dd5b3b6178b66fb2da08a02df0559a84"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7668ac04dd5b3b6178b66fb2da08a02df0559a84"}]},"branch":"refs/heads/master"},"d947237c5ac8d102f7879bcecf5e24e755f6d376":{"kind":"TRIVIAL_REBASE","_number":28,"created":"2021-10-25 14:18:42.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/28","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/28","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/28 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/28 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/28 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/28 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/28","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/28 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"da663dccdc7d5164a584c36e0437d786ac0b433a","subject":"gdb: use ptid_t::to_string in infrun debug messages","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dda663dccdc7d5164a584c36e0437d786ac0b433a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-25 14:18:17.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd947237c5ac8d102f7879bcecf5e24e755f6d376"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd947237c5ac8d102f7879bcecf5e24e755f6d376"}]},"branch":"refs/heads/master"},"e9f2774069843802a8c36d9f174c41d36611153b":{"kind":"NO_CHANGE","_number":29,"created":"2021-10-25 14:23:26.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/29","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/29","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/29 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/29 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/29 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/29 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/29","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/29 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"0af1c601d8ba370ff90a9f691fd02adacf017565","subject":"gdb: test vfork + follow parent + detach-on-fork off","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0af1c601d8ba370ff90a9f691fd02adacf017565"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-25 14:23:19.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003de9f2774069843802a8c36d9f174c41d36611153b"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003de9f2774069843802a8c36d9f174c41d36611153b"}]},"branch":"refs/heads/master"},"0ea0705e8f8c68d8a228278a9159a72f69c87d7f":{"kind":"TRIVIAL_REBASE","_number":30,"created":"2021-10-25 18:32:07.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/30","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/30","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/30 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/30 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/30 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/30 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/30","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/30 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d151594a8ec02cedbd22fd1e467d0f7cf587929a","subject":"gdb: test vfork + follow parent + detach-on-fork off","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd151594a8ec02cedbd22fd1e467d0f7cf587929a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-25 18:25:20.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0ea0705e8f8c68d8a228278a9159a72f69c87d7f"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0ea0705e8f8c68d8a228278a9159a72f69c87d7f"}]},"branch":"refs/heads/master"},"750fe2be8d2515eeb058991c7d75cbf694f82449":{"kind":"TRIVIAL_REBASE","_number":31,"created":"2021-10-25 21:14:31.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/31","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/31","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/31 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/31 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/31 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/31 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/31","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/31 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"61b254fe15bd8c73bc33af6146784a9ef2edeab9","subject":"gdb: test vfork + follow parent + detach-on-fork off","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d61b254fe15bd8c73bc33af6146784a9ef2edeab9"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-25 21:13:23.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d750fe2be8d2515eeb058991c7d75cbf694f82449"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d750fe2be8d2515eeb058991c7d75cbf694f82449"}]},"branch":"refs/heads/master"},"09e50d68b53b750ecc81810d565ed14c5b9a6573":{"kind":"TRIVIAL_REBASE","_number":32,"created":"2021-10-26 18:24:55.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/32","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/32","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/32 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/32 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/32 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/32 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/32","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/32 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"bfd397f7cd6702189fc47ef1e0290b75b87d56b9","subject":"gdb: test vfork + follow parent + detach-on-fork off","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dbfd397f7cd6702189fc47ef1e0290b75b87d56b9"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-10-26 18:14:25.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d09e50d68b53b750ecc81810d565ed14c5b9a6573"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d09e50d68b53b750ecc81810d565ed14c5b9a6573"}]},"branch":"refs/heads/master"},"302c2ba32c5d947007f6e45f84b5a1165696a70e":{"kind":"TRIVIAL_REBASE","_number":33,"created":"2021-10-28 05:43:11.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/33","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/33","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/33 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/33 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/33 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/33 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/33","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/33 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"65d20c6985c2cb8a174b96c492f83a1054e5b05a","subject":"gdb: test vfork + follow parent + detach-on-fork off","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d65d20c6985c2cb8a174b96c492f83a1054e5b05a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-10-28 00:34:45.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should not know about the fork child.  We don\u0027t know yet how the fork\nevent will be handled.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering in the remote target.  See\nremove_new_fork_children in remote.c.  In our case, the fork event\nhasn\u0027t made its way to the GDB-side remote target.  I think we need to\nimplement the same kind of logic GDBserver-side: if there\u0027s a thread /\ninferior that is the result of a fork event GDBserver hasn\u0027t reported\nyet, it should exclude that thread / inferior from the reported thread\nlist.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d302c2ba32c5d947007f6e45f84b5a1165696a70e"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d302c2ba32c5d947007f6e45f84b5a1165696a70e"}]},"branch":"refs/heads/master"},"0e38a8675d7646cfad406aca89dd91f93a288ee7":{"kind":"REWORK","_number":34,"created":"2021-10-28 16:47:33.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/34","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/34","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/34 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/34 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/34 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/34 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/34","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/34 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d6dc01baf753ea9d27b504257fef51acabaaba20","subject":"ARM assembler: Allow up to 32 single precision registers in the VPUSH and VPOP instructions.","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd6dc01baf753ea9d27b504257fef51acabaaba20"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-28 16:47:22.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0e38a8675d7646cfad406aca89dd91f93a288ee7"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d0e38a8675d7646cfad406aca89dd91f93a288ee7"}]},"branch":"refs/heads/master"},"c9397a56633b7e2d3ac5a368eae1643e346e01d4":{"kind":"TRIVIAL_REBASE","_number":35,"created":"2021-10-28 19:49:43.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/35","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/35","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/35 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/35 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/35 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/35 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/35","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/35 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cf365c10d0786a4fd2423d451596b879ee44627a","subject":"[sim] Include defs.h in ppc/hw_memory.c","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dcf365c10d0786a4fd2423d451596b879ee44627a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-28 19:16:33.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc9397a56633b7e2d3ac5a368eae1643e346e01d4"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc9397a56633b7e2d3ac5a368eae1643e346e01d4"}]},"branch":"refs/heads/master"},"8bf339d49b596cac6ae83863ad4009111ce7ae91":{"kind":"TRIVIAL_REBASE","_number":36,"created":"2021-10-28 21:11:03.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/36","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/36","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/36 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/36 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/36 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/36 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/36","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/36 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cb22a7c366838724113ac7df2703cf48aedb5273","subject":"gdb: Add OpenRISC gdbserver and native config news","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dcb22a7c366838724113ac7df2703cf48aedb5273"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-10-28 21:10:20.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d8bf339d49b596cac6ae83863ad4009111ce7ae91"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d8bf339d49b596cac6ae83863ad4009111ce7ae91"}]},"branch":"refs/heads/master"},"661ca9445eda43fd7b0dd399900b525c304340f9":{"kind":"TRIVIAL_REBASE","_number":37,"created":"2021-10-29 02:38:41.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/37","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/37","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/37 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/37 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/37 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/37 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/37","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/37 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"208eb58158c2f23a7fbaff32a4912dbbb8d0ee5c","subject":"Automatic date update in version.in","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d208eb58158c2f23a7fbaff32a4912dbbb8d0ee5c"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-10-29 01:57:43.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d661ca9445eda43fd7b0dd399900b525c304340f9"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d661ca9445eda43fd7b0dd399900b525c304340f9"}]},"branch":"refs/heads/master"},"c2053e28d83d399a22418828ed00eacfc727ddd6":{"kind":"TRIVIAL_REBASE","_number":38,"created":"2021-10-29 12:56:48.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/38","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/38","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/38 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/38 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/38 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/38 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/38","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/38 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"b88e456f7e3e6d8c354da57d3e77a98575070ee8","subject":"[gdb/build] Fix build with --disable-unit-tests","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003db88e456f7e3e6d8c354da57d3e77a98575070ee8"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-10-29 12:27:48.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another, and that other\nis reported to GDB (and the fork event stays pending in GDBserver).\nThis happens for example when we step a thread and another forks at the\nsame time.  The bug looks like (if I reproduce the included test by\nhand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - linux_process_target::wait pulls the \"single step complete SIGTRAP\"\n   and the \"fork\" events from the kernel.  It arbitrarily choses one\n   event to report, it happens to be the single-step SIGTRAP.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the code\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc2053e28d83d399a22418828ed00eacfc727ddd6"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc2053e28d83d399a22418828ed00eacfc727ddd6"}]},"branch":"refs/heads/master"},"1b4e1dd4c4d5297e42bba52ae1599e0d91c71b60":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":39,"created":"2021-10-29 20:33:24.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/39","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/39","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/39 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/39 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/39 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/39 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/39","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/39 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d3771fe234b74d60cfa553940bce9d047bd38e8d","subject":"Add gdb.Architecture.integer_type Python function","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd3771fe234b74d60cfa553940bce9d047bd38e8d"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-10-29 20:33:13.000000000","tz":-240},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1b4e1dd4c4d5297e42bba52ae1599e0d91c71b60"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1b4e1dd4c4d5297e42bba52ae1599e0d91c71b60"}]},"branch":"refs/heads/master"},"eb771d57dfcb693b1f6f6e292c85093c69f9a1cf":{"kind":"TRIVIAL_REBASE","_number":40,"created":"2021-11-12 20:59:30.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/40","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/40","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/40 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/40 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/40 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/40 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/40","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/40 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"b626a80342db07f3cc1dae45d40897f4cee1ac6e","subject":"Fix gdb.base/sigstep.exp test for ppc","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003db626a80342db07f3cc1dae45d40897f4cee1ac6e"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-12 20:59:18.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003deb771d57dfcb693b1f6f6e292c85093c69f9a1cf"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003deb771d57dfcb693b1f6f6e292c85093c69f9a1cf"}]},"branch":"refs/heads/master"},"9a161181f75b0eea18facab5b554667d354cc265":{"kind":"TRIVIAL_REBASE","_number":41,"created":"2021-11-13 02:08:18.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/41","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/41","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/41 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/41 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/41 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/41 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/41","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/41 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d83136b8016f830283adb27bb6a771a4cefa67ee","subject":"gdb: rework \"set debuginfod\" commands","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd83136b8016f830283adb27bb6a771a4cefa67ee"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-13 02:08:18.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9a161181f75b0eea18facab5b554667d354cc265"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9a161181f75b0eea18facab5b554667d354cc265"}]},"branch":"refs/heads/master","description":"Rebase"},"7aeaed600c4cf438c35d00b91d4af16aeedf2ef1":{"kind":"TRIVIAL_REBASE","_number":42,"created":"2021-11-14 13:29:51.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/42","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/42","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/42 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/42 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/42 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/42 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/42","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/42 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"2d59313bbe5cb2d61a6936ea9977faa7a77267db","subject":"gdb: rework \"set debuginfod\" commands","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d2d59313bbe5cb2d61a6936ea9977faa7a77267db"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-14 13:29:43.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7aeaed600c4cf438c35d00b91d4af16aeedf2ef1"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7aeaed600c4cf438c35d00b91d4af16aeedf2ef1"}]},"branch":"refs/heads/master"},"004ca1a837c828459d24f046bb859cb62c1bd5cf":{"kind":"TRIVIAL_REBASE","_number":43,"created":"2021-11-16 18:35:13.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/43","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/43","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/43 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/43 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/43 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/43 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/43","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/43 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"a6e7fea128b8e1da3ea99dc906df56f85589d335","subject":"gdb: throw OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da6e7fea128b8e1da3ea99dc906df56f85589d335"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-16 18:35:03.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d004ca1a837c828459d24f046bb859cb62c1bd5cf"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d004ca1a837c828459d24f046bb859cb62c1bd5cf"}]},"branch":"refs/heads/master"},"9a4a64999c23e97dda16a7b7fc0b83c9d68a940b":{"kind":"TRIVIAL_REBASE","_number":44,"created":"2021-11-16 21:26:39.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/44","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/44","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/44 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/44 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/44 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/44 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/44","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/44 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"a7fd11862703e45d2774981a4888bc127d473b06","subject":"readelf: Support SHT_RELR/DT_RELR for -r","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da7fd11862703e45d2774981a4888bc127d473b06"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-16 21:26:31.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9a4a64999c23e97dda16a7b7fc0b83c9d68a940b"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9a4a64999c23e97dda16a7b7fc0b83c9d68a940b"}]},"branch":"refs/heads/master"},"d76084d191d4340866537cde366d2c6765f46795":{"kind":"TRIVIAL_REBASE","_number":45,"created":"2021-11-17 20:57:12.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/45","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/45","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/45 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/45 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/45 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/45 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/45","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/45 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cac6c0f26d8469bd5d506e0066504f0ef12e387b","subject":"gdb: pass more const target_waitstatus by reference","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dcac6c0f26d8469bd5d506e0066504f0ef12e387b"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-17 20:56:56.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd76084d191d4340866537cde366d2c6765f46795"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dd76084d191d4340866537cde366d2c6765f46795"}]},"branch":"refs/heads/master"},"c66e8efd902f555d8cf54d4a26fa13dd936273b2":{"kind":"TRIVIAL_REBASE","_number":46,"created":"2021-11-18 20:08:21.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/46","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/46","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/46 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/46 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/46 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/46 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/46","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/46 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5567669607e765a8903e69e4c1dcb173813fe75c","subject":"gdb: pass more const target_waitstatus by reference","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d5567669607e765a8903e69e4c1dcb173813fe75c"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-18 19:03:24.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc66e8efd902f555d8cf54d4a26fa13dd936273b2"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc66e8efd902f555d8cf54d4a26fa13dd936273b2"}]},"branch":"refs/heads/master"},"416371486cd9938533bbe5a5ab1c7cd99460fdbf":{"kind":"TRIVIAL_REBASE","_number":47,"created":"2021-11-22 16:26:33.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/47","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/47","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/47 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/47 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/47 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/47 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/47","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/47 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"b129faa9d8cebee73f5790fa101b1ddd62a6f2c4","subject":"gdb: pass more const target_waitstatus by reference","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003db129faa9d8cebee73f5790fa101b1ddd62a6f2c4"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-22 16:26:28.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d416371486cd9938533bbe5a5ab1c7cd99460fdbf"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d416371486cd9938533bbe5a5ab1c7cd99460fdbf"}]},"branch":"refs/heads/master"},"a974048b686f199a88543c880c00675a25e842f1":{"kind":"NO_CHANGE","_number":48,"created":"2021-11-22 20:11:02.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/48","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/48","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/48 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/48 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/48 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/48 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/48","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/48 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"c272a98cbf596ddf1a70a41801c6e86d9564d152","subject":"gdb: pass more const target_waitstatus by reference","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc272a98cbf596ddf1a70a41801c6e86d9564d152"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-22 19:02:13.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da974048b686f199a88543c880c00675a25e842f1"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da974048b686f199a88543c880c00675a25e842f1"}]},"branch":"refs/heads/master"},"1533321bda951a806f59fb87e7fcb9adb131f59b":{"kind":"TRIVIAL_REBASE","_number":49,"created":"2021-11-23 03:43:41.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/49","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/49","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/49 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/49 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/49 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/49 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/49","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/49 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"9f6148cb8538a11f39eb938d4d8bf1eaba31f6af","subject":"gdb: more compile fixes for gnu-nat.c","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9f6148cb8538a11f39eb938d4d8bf1eaba31f6af"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-23 03:43:12.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1533321bda951a806f59fb87e7fcb9adb131f59b"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1533321bda951a806f59fb87e7fcb9adb131f59b"}]},"branch":"refs/heads/master"},"85c4ff43733e91d2f4d6f1519c889f13fff50f28":{"kind":"TRIVIAL_REBASE","_number":50,"created":"2021-11-24 19:58:31.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/50","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/50","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/50 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/50 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/50 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/50 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/50","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/50 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"e19f8248297bb9864ff14368cc89d2446572837a","subject":"Revert (part of) \"gdb fix for catch-syscall.exp\"","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003de19f8248297bb9864ff14368cc89d2446572837a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-09-28 20:58:26.000000000","tz":-240},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-24 19:38:24.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d85c4ff43733e91d2f4d6f1519c889f13fff50f28"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d85c4ff43733e91d2f4d6f1519c889f13fff50f28"}]},"branch":"refs/heads/master"},"a3c151668a8413ec6f66f090ec9d4cd9274a34f8":{"kind":"REWORK","_number":51,"created":"2021-11-27 04:15:57.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/51","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/51","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/51 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/51 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/51 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/51 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/51","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/51 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"429a55b86557883a18e9c6405918825eb6eafd28","subject":"sim: testsuite: fix bits-gen EXEEXT handling","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d429a55b86557883a18e9c6405918825eb6eafd28"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-27 04:15:39.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da3c151668a8413ec6f66f090ec9d4cd9274a34f8"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da3c151668a8413ec6f66f090ec9d4cd9274a34f8"}]},"branch":"refs/heads/master"},"15fde5ba14e5b99ffd03d316603deb6aa603a03d":{"kind":"TRIVIAL_REBASE","_number":52,"created":"2021-11-27 15:12:11.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/52","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/52","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/52 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/52 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/52 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/52 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/52","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/52 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6916d9e65c5bc69b469964ae7202c33b309558a4","subject":"sim: testsuite: add dedicated flag for init toolchain tests","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d6916d9e65c5bc69b469964ae7202c33b309558a4"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-11-27 15:01:56.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d15fde5ba14e5b99ffd03d316603deb6aa603a03d"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d15fde5ba14e5b99ffd03d316603deb6aa603a03d"}]},"branch":"refs/heads/master"},"3c06f7e20856ca16df5df667ad5819d55763b3fa":{"kind":"TRIVIAL_REBASE","_number":53,"created":"2021-11-28 13:10:04.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/53","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/53","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/53 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/53 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/53 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/53 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/53","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/53 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"96537189c92734cad48c95de00d3cd167ad7092d","subject":"sim: frv: resolve syscalls dynamically","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d96537189c92734cad48c95de00d3cd167ad7092d"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-28 13:09:51.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3c06f7e20856ca16df5df667ad5819d55763b3fa"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d3c06f7e20856ca16df5df667ad5819d55763b3fa"}]},"branch":"refs/heads/master"},"6c4065b6bca20378afbfac795b6c885a12d6c624":{"kind":"REWORK","_number":54,"created":"2021-11-29 14:27:30.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/54","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/54","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/54 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/54 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/54 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/54 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/54","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/54 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"c2611492786971de47464246b8271d6a6ab9421a","subject":"[gdb/testsuite] Fix typo in proc lines","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003dc2611492786971de47464246b8271d6a6ab9421a"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-29 13:05:37.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d6c4065b6bca20378afbfac795b6c885a12d6c624"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d6c4065b6bca20378afbfac795b6c885a12d6c624"}]},"branch":"refs/heads/master"},"1286a362484e04740a8ed4f47757fdd326e71caa":{"kind":"REWORK","_number":55,"created":"2021-11-30 19:12:46.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/55","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/55","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/55 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/55 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/55 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/55 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/55","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/55 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5f15e2819f0a4f7e566f33074e672c3e0ed3aca2","subject":"gdbserver/tracepoint.cc: work around -Wstringop-truncation error","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d5f15e2819f0a4f7e566f33074e672c3e0ed3aca2"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-30 19:12:36.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1286a362484e04740a8ed4f47757fdd326e71caa"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d1286a362484e04740a8ed4f47757fdd326e71caa"}]},"branch":"refs/heads/master"},"5a690762c8ce18570867eaf04a4cf2347471e4c7":{"kind":"TRIVIAL_REBASE","_number":56,"created":"2021-11-30 19:26:55.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/56","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/56","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/56 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/56 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/56 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/56 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/56","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/56 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"51452747c839d7321910aaafcd9763ba0e39c334","subject":"gdbserver/tracepoint.cc: work around -Wstringop-truncation error","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d51452747c839d7321910aaafcd9763ba0e39c334"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-30 19:26:19.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d5a690762c8ce18570867eaf04a4cf2347471e4c7"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d5a690762c8ce18570867eaf04a4cf2347471e4c7"}]},"branch":"refs/heads/master"},"df12aaa75e777535e685e6747e89df7e5208deb3":{"kind":"TRIVIAL_REBASE","_number":57,"created":"2021-12-01 00:58:48.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/57","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/57","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/57 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/57 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/57 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/57 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/57","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/57 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"988fcfd20b926aa16682a175beffbc1370ff5ca2","subject":"gdbserver/tracepoint.cc: work around -Wstringop-truncation error","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d988fcfd20b926aa16682a175beffbc1370ff5ca2"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-12-01 00:58:39.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003ddf12aaa75e777535e685e6747e89df7e5208deb3"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003ddf12aaa75e777535e685e6747e89df7e5208deb3"}]},"branch":"refs/heads/master"},"4ae1caaa84bcbd739f885eb051eb29d5d9e54e6f":{"kind":"TRIVIAL_REBASE","_number":58,"created":"2021-12-01 02:16:55.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/58","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/58","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/58 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/58 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/58 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/58 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/58","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/58 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"786dde3f6948c432022d31b2f8f8c921a25556f5","subject":"gdbserver/tracepoint.cc: work around -Wstringop-truncation error","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d786dde3f6948c432022d31b2f8f8c921a25556f5"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-12-01 02:16:45.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d4ae1caaa84bcbd739f885eb051eb29d5d9e54e6f"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d4ae1caaa84bcbd739f885eb051eb29d5d9e54e6f"}]},"branch":"refs/heads/master"},"738366e2bc437bbdecce57ff8a371c928d3691d0":{"kind":"NO_CHANGE","_number":59,"created":"2021-12-01 02:50:52.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/59","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/59","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/59 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/59 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/59 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/59 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/59","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/59 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"349b411c0dbb950da61295f19d7be572471b7ff7","subject":"gdbserver/tracepoint.cc: work around -Wstringop-truncation error","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d349b411c0dbb950da61295f19d7be572471b7ff7"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-12-01 02:50:46.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d738366e2bc437bbdecce57ff8a371c928d3691d0"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d738366e2bc437bbdecce57ff8a371c928d3691d0"}]},"branch":"refs/heads/master"},"66aab9fb16e01b033b4226c67cb5711f8e20c618":{"kind":"TRIVIAL_REBASE","_number":60,"created":"2021-12-01 14:23:53.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/60","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/60","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/60 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/60 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/60 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/60 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/60","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/60 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"48dd3c19247a653256160fa03cd1d521e17b1b2c","subject":"gdbserver/tracepoint.cc: work around -Wstringop-truncation error","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d48dd3c19247a653256160fa03cd1d521e17b1b2c"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-11-24 20:04:42.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-12-01 14:23:42.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  Move this\ninformation to the common thread_info structure, so that it can be used\nin handle_qxfer_threads_worker to filter out unreported fork child\nthreads.  Plus, that makes it usable for other OSes that use fork if\nneed be.\n\nI split the field in two (fork_parent / fork_child), I think it\u0027s\nclearer this way, easier to follow which thread is the parent and which\nis the child, and helps ensure things are consistent.  That simplifies\nthings a bit in linux_set_resume_request.  Currently, when\nlwp-\u003efork_relative is set, we have to deduce whether this is a parent or\nchild using the pending event.  With separate fork_parent and fork_child\nfields, it becomes more obvious.  If the thread has a fork parent, then\nit means it\u0027s a fork child, and vice-versa.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d66aab9fb16e01b033b4226c67cb5711f8e20c618"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d66aab9fb16e01b033b4226c67cb5711f8e20c618"}]},"branch":"refs/heads/master"},"39d0c4e547fa15cd1b5d346e805e919605d8cd27":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":61,"created":"2021-12-01 15:30:57.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/61","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/61","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/61 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/61 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/61 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/61 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/61","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/61 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"e5382207cdddea07c6456fc1c0e6bea73b3d9947","subject":"readelf: recognize FDO Packaging Metadata ELF note","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003de5382207cdddea07c6456fc1c0e6bea73b3d9947"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-12-01 14:40:02.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-12-01 15:30:43.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  This information\nneeds to be made available to the handle_qxfer_threads_worker function,\nso it can filter the reported threads.  Add a new thread_pending_parent\ntarget function that allows the Linux target to return the parent of an\neventual fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d39d0c4e547fa15cd1b5d346e805e919605d8cd27"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d39d0c4e547fa15cd1b5d346e805e919605d8cd27"}]},"branch":"refs/heads/master"},"193410ede2f69977d92dbdaf7704ec7093e19030":{"kind":"TRIVIAL_REBASE","_number":62,"created":"2021-12-04 03:35:51.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/62","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/62","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/62 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/62 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/62 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/62 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/62","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/62 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"a3e9c2f9da9ab84bb5f0d1e6dc7e99e6114ade39","subject":"gdb/testsuite: fix two \"maint info line-table\"-related tests","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003da3e9c2f9da9ab84bb5f0d1e6dc7e99e6114ade39"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-12-01 14:40:02.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@polymtl.ca","date":"2021-12-04 02:16:27.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  This information\nneeds to be made available to the handle_qxfer_threads_worker function,\nso it can filter the reported threads.  Add a new thread_pending_parent\ntarget function that allows the Linux target to return the parent of an\neventual fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d193410ede2f69977d92dbdaf7704ec7093e19030"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d193410ede2f69977d92dbdaf7704ec7093e19030"}]},"branch":"refs/heads/master"},"7b961964f86618773218c067bfff066b2bff8328":{"kind":"TRIVIAL_REBASE","_number":63,"created":"2021-12-09 02:01:00.000000000","uploader":{"_account_id":1000001,"name":"Simon Marchi","email":"simon.marchi@efficios.com","username":"simark","avatars":[{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d32","height":32},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d56","height":56},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d100","height":100},{"url":"https://www.gravatar.com/avatar/5f66b515fa1c72f5ab184df919253b2f.jpg?d\u003dretro\u0026r\u003dr\u0026s\u003d120","height":120}]},"ref":"refs/changes/87/6187/63","fetch":{"anonymous http":{"url":"https://review.lttng.org/binutils-gdb","ref":"refs/changes/87/6187/63","commands":{"Branch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/63 \u0026\u0026 git checkout -b change-6187 FETCH_HEAD","Checkout":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/63 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/63 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/63 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.lttng.org/binutils-gdb refs/changes/87/6187/63","Reset To":"git fetch https://review.lttng.org/binutils-gdb refs/changes/87/6187/63 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"9aecb5778dee567c8581185a4b9badeb8d565997","subject":"Automatic date update in version.in","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d9aecb5778dee567c8581185a4b9badeb8d565997"}]}],"author":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-12-01 14:40:02.000000000","tz":-300},"committer":{"name":"Simon Marchi","email":"simon.marchi@efficios.com","date":"2021-12-09 02:00:39.000000000","tz":-300},"subject":"gdbserver: hide fork child threads from GDB","message":"gdbserver: hide fork child threads from GDB\n\nThis patch aims at fixing a bug where an inferior is unexpectedly\ncreated when a fork happens at the same time as another event, and that\nother event is reported to GDB first (and the fork event stays pending\nin GDBserver).  This happens for example when we step a thread and\nanother thread forks at the same time.  The bug looks like (if I\nreproduce the included test by hand):\n\n    (gdb) show detach-on-fork\n    Whether gdb will detach the child of a fork is on.\n    (gdb) show follow-fork-mode\n    Debugger response to a program call of fork or vfork is \"parent\".\n    (gdb) si\n    [New inferior 2]\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...\n    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...\n    [New Thread 965190.965190]\n    [Switching to Thread 965190.965190]\n    Remote \u0027g\u0027 packet reply is too long (expected 560 bytes, got 816 bytes): ... \u003clong series of bytes\u003e\n\nThe sequence of events leading to the problem is:\n\n - We are using the all-stop user-visible mode as well as the\n   synchronous / all-stop variant of the remote protocol\n - We have two threads, thread A that we single-step and thread B that\n   calls fork at the same time\n - GDBserver\u0027s linux_process_target::wait pulls the \"single step\n   complete SIGTRAP\" and the \"fork\" events from the kernel.  It\n   arbitrarily choses one event to report, it happens to be the\n   single-step SIGTRAP.  The fork stays pending in the thread_info.\n - GDBserver send that SIGTRAP as a stop reply to GDB\n - While in stop_all_threads, GDB calls update_thread_list, which ends\n   up querying the remote thread list using qXfer:threads:read.\n - In the reply, GDBserver includes the fork child created as a result\n   of thread B\u0027s fork.\n - GDB-side, the remote target sees the new PID, calls\n   remote_notice_new_inferior, which ends up unexpectedly creating a new\n   inferior, and things go downhill from there.\n\nThe problem here is that as long as GDB did not process the fork event,\nit should pretend the fork child does not exist.  Ultimately, this event\nwill be reported, we\u0027ll go through follow_fork, and that process will be\ndetached.\n\nThe remote target (GDB-side), has some code to remove from the reported\nthread list the threads that are the result of forks not processed by\nGDB yet.  But that only works for fork events that have made their way\nto the remote target (GDB-side), but haven\u0027t been consumed by the core\nyet, so are still lingering as pending stop replies in the remote target\n(see remove_new_fork_children in remote.c).  But in our case, the fork\nevent hasn\u0027t made its way to the GDB-side remote target.  We need to\nimplement the same kind of logic GDBserver-side: if there exists a\nthread / inferior that is the result of a fork event GDBserver hasn\u0027t\nreported yet, it should exclude that thread / inferior from the reported\nthread list.\n\nThis was actually discussed a while ago, but not implemented AFAIK:\n\n    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t\n    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html\n\nImplementation details-wise, the fix for this is all in GDBserver.  The\nLinux layer of GDBserver already tracks unreported fork parent / child\nrelationships using the lwp_info::fork_relative, in order to avoid\nwildcard actions resuming fork childs unknown to GDB.  This information\nneeds to be made available to the handle_qxfer_threads_worker function,\nso it can filter the reported threads.  Add a new thread_pending_parent\ntarget function that allows the Linux target to return the parent of an\neventual fork child.\n\nTesting-wise, the test replicates pretty-much the sequence of events\nshown above.  The setup of the test makes it such that the main thread\nis about to fork.  We stepi the other thread, so that the step completes\nvery quickly, in a single event.  Meanwhile, the main thread is resumed,\nso very likely has time to call fork.  This means that the bug may not\nreproduce every time (if the main thread does not have time to call\nfork), but it will reproduce more often than not.  The test fails\nwithout the fix applied on the native-gdbserver and\nnative-extended-gdbserver boards.\n\nAt some point I suspected that which thread called fork and which thread\ndid the step influenced the order in which the events were reported, and\ntherefore the reproducibility of the bug.  So I made the test try  both\ncombinations: main thread forks while other thread steps, and vice\nversa.  I\u0027m not sure this is still necessary, but I left it there\nanyway.  It doesn\u0027t hurt to test a few more combinations.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d28288\nChange-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990\n","web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7b961964f86618773218c067bfff066b2bff8328"}],"resolve_conflicts_web_links":[{"name":"gitweb","tooltip":"Open in GitWeb","url":"/gitweb?p\u003dbinutils-gdb.git;a\u003dcommit;h\u003d7b961964f86618773218c067bfff066b2bff8328"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}