From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22387 invoked by alias); 15 May 2003 21:26:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22301 invoked from network); 15 May 2003 21:25:58 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 15 May 2003 21:25:58 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h4FLPiZN000358; Thu, 15 May 2003 23:25:44 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h4FLPiHD000433; Thu, 15 May 2003 23:25:44 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h4FLPhd8000430; Thu, 15 May 2003 23:25:43 +0200 (CEST) Date: Thu, 15 May 2003 21:26:00 -0000 Message-Id: <200305152125.h4FLPhd8000430@elgar.kettenis.dyndns.org> From: Mark Kettenis To: roland@redhat.com CC: gdb@sources.redhat.com In-reply-to: <200305130153.h4D1rGW23237@magilla.sf.frob.com> (message from Roland McGrath on Mon, 12 May 2003 18:53:16 -0700) Subject: Re: gdb support for Linux vsyscall DSO References: <200305130153.h4D1rGW23237@magilla.sf.frob.com> X-SW-Source: 2003-05/txt/msg00240.txt.bz2 Date: Mon, 12 May 2003 18:53:16 -0700 From: Roland McGrath > There is some special handling for signal trampolines in > infrun.c:handle_inferior_event(). Beware! Dragons can still be found > in that function. However, it seems the bit of code I'm talking about > is there for targets that don't known how to properly unwind signal > frames :-). I only partly follow the code in that function, but it does look like it wants to know whether it's in a signal frame. I get the impression that "next" or "step" interrupted by a signal lets the signal be handled and continues until the end of the source line rather than doing a normal user stop for the signal, and that this is considered desireable. So it must know. I'm not really sure. The code I referred to seems to be written for BSD-style signal trampolines, where the signal trampoline will call the signal handler. The Linux kernel calls the signal trampoline directly, so perhaps it doesn't need this code. Having a DWARF2 extension to mark signal frames seems reasonable, and less kludgey than matching symbol names. However, I wonder if there is in fact a way to do it that won't confuse older libgcc's .eh_frame unwinding code. If the `z' augmentation doesn't confuse older libgcc's, I don't see why adding another augmentation would do so. But we should first determine if we really need it before adding it. > Restoring %eflags is certainly possible. Making GDB actually pop the > signal trampoline frame should work I only mentioned %eflags to pedantic because I caught myself about to say "restore the exact state of the interrupted thread" and that wasn't completely true. I don't anticipate gdb having any reason to want to roll back a signal frame. (However, in the abstract it seems like the right thing for the kernel unwind info to describe restoring %eflags if the DWARF2 format can already represent that.) Well, GDB will do exactly that when the user gives the "return" command in a signal trampoline. Mark