From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16628 invoked by alias); 25 Oct 2011 18:12:51 -0000 Received: (qmail 16619 invoked by uid 22791); 25 Oct 2011 18:12:50 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Oct 2011 18:12:34 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RIlUG-0002ye-UK from pedro_alves@mentor.com ; Tue, 25 Oct 2011 11:12:33 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2011 19:12:30 +0100 From: Pedro Alves To: Oleg Nesterov Subject: Re: FYI: fix 2 tests when glibc debuginfo is installed Date: Tue, 25 Oct 2011 18:16:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: Jan Kratochvil , gdb-patches@sourceware.org, Tom Tromey References: <201110251755.12986.pedro@codesourcery.com> <20111025173249.GA23231@redhat.com> In-Reply-To: <20111025173249.GA23231@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110251912.26857.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00669.txt.bz2 On Tuesday 25 October 2011 18:32:49, Oleg Nesterov wrote: > On 10/25, Pedro Alves wrote: > > Thanks. Okay, so I take it what really happens is that PTRACE_ATTACH no > > longer messes with job control, > > Well, PTRACE_ATTACH was not really changed in this sense. Ah, okay. > And it still sends SIGSTOP. You can use PTRACE_SEIZE. That I know. :-) I was trying to understand what happens to older gdb's on new kernels, and, if gdb needs to adapt, and if it needs to detect whether what "flavor" of PTRACE_ATTACH|DETACH it is talking to. > But I guess this is off-topic, > > and that gdb will have to > > `kill -SIGCONT' the inferior itself if it wants e.g., inferior > > function calls to work after attaching to a stopped process > > Why? PTRACE_CONT/etc should work. The tracee will be resumed, stopped > or not. Eh, well, I read some discussions from earlier this year on lkml proposing that, and I guess I got confused. > But, compared to the old kernels, the tracee "remembers" the > fact it was stopped, and it will stop again after DETACH. Unless SIGCONT > in between. What about PTRACE_CONT in between (no SIGCONT)? Does it make the kernel "forget" the fact that the child was stopped before? If not, what happens if the ptracer dies while its child is PTRACE_CONT'ed, and the child was stopped at PTRACE_ATTACH time? -- Pedro Alves