From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30761 invoked by alias); 10 May 2003 20:27:23 -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 30711 invoked from network); 10 May 2003 20:27:22 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 10 May 2003 20:27:22 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 3DB0B354C; Sat, 10 May 2003 13:27:21 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4AKRKM00391; Sat, 10 May 2003 13:27:20 -0700 Date: Sat, 10 May 2003 20:27:00 -0000 Message-Id: <200305102027.h4AKRKM00391@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 Saturday, 10 May 2003 19:55:40 +0200 <200305101755.h4AHteOW075597@elgar.kettenis.dyndns.org> Emacs: resistance is futile; you will be assimilated and byte-compiled. X-SW-Source: 2003-05/txt/msg00190.txt.bz2 > No work has yet been done to convert GDB's ia64 target to make it use > the new frame unwinder framework. Andrew's idea was that it should be > possible to just hook the frame unwind methods into an existing > target, but that hasn't been tested yet. Ok. I am not going to worry about IA64 work per se for now. I mentioned it because the DSO issues are the same as the x86 case and so most of the work I've suggested can be machine-independent. > The run-time dynamic linker's data structures usually are intact, but > a fall-back mechanism wouldn't hurt I guess. The stack is usually intact too. ;-) It would not be the end of the world to rely on the dynamic linker's data structures. In practice, they are intact and people don't use the vsyscall entrypoint in statically linked programs. But I would rather consider *that* the fallback to be used in remote situations where the kernel inquiry mechanism isn't available. If there is a kernel inquiry mechanism, it will always be correct. If there are dynamic linker data structures at all, they might be bogus so you don't want to use them preferentially. > OK, as long as we try to keep the code as generic as possible and > isolate platform-specific hacks in platform-specific files. You know me. > Note that symbols from the vsyscall would be very helpful to the user. Surely. But lack thereof doesn't cripple the user the way failure to unwind the frame does, so it's not the highest priority. That's all I said. > There is also an issue with signal trampolines. GDB needs to be able > to recognize them in order to support stepping over functions when a > signal arrives. I don't think I know exactly what you mean here. Is there a special case for signal frames aside from just knowing how to unwind them properly? (The only other specialness I am aware of is "", which with normal unwind info would show __kernel_sigreturn instead.) > I proposed Richard Henderson to add a special DWARF CFI augmentation to > mark __kernel_sigreturn and __kernel_rt_sigreturn as signal trampolines. > That would allow me to recognize them without knowing their names. The code I have seen looks at the instruction sequence to match the expected system call (using "int $0x80"). All extant Linux kernels still have those same exact instruction sequences (as libc's __restore and __restore_rt). So this will continue to work, ugly as it is. Not that we shouldn't address it more cleanly, but I don't think it's in fact breaking anything at this very moment. rth has added unwind info to the __kernel_{rt_,}sigreturn vsyscall code. These describe unwinding the signal frame to restore all the registers to the state that was interrupted by the signal (though not the processor flags word, I dunno if i386 DWARF2 format can do that--you'd only need that if you wanted to roll back the signal handling frame as if it had never happened at all, not just to unwind past it or examine the frame's state). > Ordinary shared libraries are cleared out in core_close() by > CLEAR_SOLIB(). This calls solib.c:clear_solib(), so I think you > should remove things in that codepath. Ok. > Relying on the dynamic linker's data structures certainly seems > attractive to me as an additional method since it works independently > of the remote protocol. Agreed. I was vaguely hoping that someone would have a brilliant idea that is both remote-friendly and as robust as the kernel-specific backend solutions, but I don't think there is one possible. > To avoid kludging around one could: These are the obvious suggestions. I am very hesitant to change the exposed structures; frankly, those two will probably never change again. The dynamic tag would be a convenient one, but would require an ld change and to be sure your kernel was built by a new enough ld; that is impractical. Exposing some way to get the l_phdr pointer is very reasonable. An idea that doesn't raise many of the issues of changing the public `struct link_map' layout is export an internal symbol giving offsetof (struct link_map, l_phdr). That is still sort of a kludge if you ask me. But it shouldn't cause many problems in practice. > to make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way > > That would probably be better that reading /proc/PID/auxv out of the > process stack. Agreed.