From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32098 invoked by alias); 16 May 2003 02:25:44 -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 31917 invoked from network); 16 May 2003 02:25:41 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 16 May 2003 02:25:41 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 9F7DA354C; Thu, 15 May 2003 19:25:40 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4G2PdN28368; Thu, 15 May 2003 19:25:39 -0700 Date: Fri, 16 May 2003 02:25:00 -0000 Message-Id: <200305160225.h4G2PdN28368@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO In-Reply-To: Mark Kettenis's message of Thursday, 15 May 2003 23:25:43 +0200 <200305152125.h4FLPhd8000430@elgar.kettenis.dyndns.org> X-Zippy-Says: Maybe we could paint GOLDIE HAWN a rich PRUSSIAN BLUE-- X-SW-Source: 2003-05/txt/msg00241.txt.bz2 > 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. I assume you meant "calls the signal handler directly" here. I don't know off hand what other systems do. Linux does point the PC directly at the signal handler, but the return address on its stack is the sigreturn code. So once the handler function is entered, the register and stack state looks like that code was the caller. > 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. Oh, I see. It hadn't occurred to me you meant an augmentation addition, and I was thinking of new opcodes or something like that. > Well, GDB will do exactly that when the user gives the "return" > command in a signal trampoline. Does that need to work? Does it really work now? (Using "return" in a signal handler function should work fine, and that is what seems like it would matter.)