Я пишу ориентированный на GUI отладчик, который ориентирован в первую очередь на Linux, но я планирую порты для других ОС в будущем. Поскольку графический интерфейс должен всегда оставаться интерактивным, у меня есть несколько потоков, обрабатывающих разные вещи.
Прежде всего, у меня есть поток "событие отладки", который просто зацикливается на ожидании возврата waitpid и доставляет полученные события другим потокам. Я делаю это потому, что у waitpid нет тайм-аута, что делает его очень трудным интегрировать его с другими циклами событий и поддерживать отзывчивость (waitpid может зависать бесконечно!).
Эта стратегия до сих пор прекрасно работала для сборок Linux. В последнее время я пытался информировать мой поток отладчика (как в потоках отлаживаемого приложения, а не в самом отладчике).
Поэтому я установил параметры ptrace для отслеживания событий клонирования и поиска состояния, для которого верхний 16-разрядный бит установлен на PTRACE_EVENT_CLONE
. Затем я использую PTRACE_GETEVENTMSG
, чтобы получить TID нового потока. Все это прекрасно работает в моих маленьких приложениях для тестирования. Но по какой-то причине он терпит неудачу, когда я помещаю этот код в свой настоящий отладчик. (Я получаю код ошибки «Нет такого процесса»)
Единственное, что мне пришло в голову, это то, что в Windows есть правило, что только поток, прикрепленный к приложению, может прослушивать события отладки. Есть ли у Linux ptrace подобное ограничение? Если так, почему мой код работает для других событий отладки?
EDIT:
Похоже, что по крайней мере waitpid поддерживает ожидание из другого потока, на странице руководства написано:
До Linux 2.4 поток был просто
частный случай процесса, и как
следствие одна нить не могла дождаться
дети из другого потока, даже когда
последний принадлежит той же теме
группа. Тем не менее, POSIX предписывает
такая функциональность, а с Linux 2.4 а
нить может и по умолчанию
будет ждать детей других
темы в одной группе.
Так что самое большее это ограничение ptrace.