From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24152 invoked by alias); 3 Sep 2010 19:59:19 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 24141 invoked by uid 22791); 3 Sep 2010 19:59:18 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jan Kratochvil X-Fcc: ~/Mail/utrace Cc: Oleg Nesterov , utrace-devel@redhat.com, archer@sourceware.org Subject: Re: gdbstub initial code, v7 In-Reply-To: Jan Kratochvil's message of Friday, 3 September 2010 08:40:08 +0200 <20100903064008.GA16249@host1.dyn.jankratochvil.net> References: <20100830185850.GA1132@redhat.com> <20100830192040.GA15431@host1.dyn.jankratochvil.net> <20100831072048.GA26362@host1.dyn.jankratochvil.net> <20100902200632.GA23692@redhat.com> <20100903064008.GA16249@host1.dyn.jankratochvil.net> Message-Id: <20100903195906.406D5401B3@magilla.sf.frob.com> Date: Fri, 03 Sep 2010 19:59:00 -0000 X-SW-Source: 2010-q3/txt/msg00140.txt.bz2 > Currently GDB does not do anything special, that is if there is siginfo for > signal SIGUSR1 but one does $C0B (SIGSEGV) does ptrace reset the siginfo or is > left the SIGUSR1 siginfo for SIGSEGV? The kernel considers this sloppy behavior on the debugger's part. If you inject a different signal, we expect you should PTRACE_SETSIGINFO to something appropriate, or else that you really didn't care about the bits being accurate. If the resumption signal does not match the siginfo_t.si_signo, then the kernel resets the siginfo as if the debugger had just used kill with the new signal (i.e. si_pid, si_uid point to the ptracer). Thanks, Roland