From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127241 invoked by alias); 21 Jul 2016 23:41:18 -0000 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 Received: (qmail 127231 invoked by uid 89); 21 Jul 2016 23:41:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=mti, MTI, H*r:Fri, Absolutely X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Jul 2016 23:41:15 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 77CFF5C92E2EB; Fri, 22 Jul 2016 00:40:58 +0100 (IST) Received: from [10.20.78.106] (10.20.78.106) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Fri, 22 Jul 2016 00:41:01 +0100 Date: Thu, 21 Jul 2016 23:41:00 -0000 From: "Maciej W. Rozycki" To: CC: , , Subject: Re: [RFA 5/6] Remove unused variables In-Reply-To: <261F6870-E91C-4747-8B21-10493AD8550C@dell.com> Message-ID: References: <1465248812-23902-1-git-send-email-tom@tromey.com> <1465248812-23902-6-git-send-email-tom@tromey.com> <87wpl9t4l2.fsf@tromey.com> <87furdnubd.fsf@tromey.com> <261F6870-E91C-4747-8B21-10493AD8550C@dell.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-07/txt/msg00272.txt.bz2 On Wed, 20 Jul 2016, Paul_Koning@Dell.com wrote: > > Overall with recent and less so improvements to GCC's and other > > compilers' optimizers I think these heuristic unwinders have hardly any > > value nowadays, they seem unable to get through function prologues > > containing arbitrary instructions thrown there by the scheduler. This is > > very annoying in a common case where you interrupt a debuggee in the > > middle of a sleeping syscall, with no way to backtrace through stripped > > system shared libraries. > > My experience is that the heuristic unwinders can be made to handle a > lot of what's thrown at them now, but it takes quite a lot of extra > heuristics to do so. I have much of this on an internal version. > Should I look into making them available? Absolutely! > One thing I've done that may not be generally interesting: make the > unwinders work in the kernel (NetBSD) and able to unwind across > exception frames so you can use kernel debugging and see the stack all > the way into the calling process. I haven't found this all that > interesting in online debugging, but it has sometimes been useful in > analyzing kernel crash dumps. I think it's a separate matter -- and for post-mortem debugging (and even live debugging e.g. with QEMU's integrated debug stub or if you're a lucky one who has JTAG probe hardware to hand) you can actually implement an exception frame sniffer/unwinder so that GDB can examine it automagically. As an example see mips-sde-tdep.c, handling exception frames from the old Algorithmics/MTI SDE toolkit/board support package. If you'd like to add a similar handler for the NetBSD kernel, then I'll gladly accept it. In a typical user app debug scenario you have cases where you want to interrupt the program and see where it is, examine its local state, often in the function that made the C library call which ended up in the syscall just interrupted. In the absence of either debug information all the way through the syscall's entry point or special support it does not work however with ABIs such as these used with the MIPS processor, where the structure of the stack frame is variable and you cannot backtrace by just taking the value from the frame pointer register and using it recursively to fetch previous frame pointers from the stack. Unlike say with x86 or Power, where you may not be able to get complete information about the innermost or some intermediate frames, but at least you can backtrace far enough to reach a frame associated with a function from your actual program being debugged and be able to fully examine the state there as well as within any previous frames. Based on my personal experience with debugging software I think it is a serious shortcoming of the MIPS backend, so if you have a way to improve the current situation, then by any means please share it and make people's life easier. It'll be a huge step forward even if sometime in the future we may get ourselves other means, such as what I have outlined in my previous e-mail or maybe yet something else. Maciej