From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18306 invoked by alias); 30 Dec 2009 08:06:20 -0000 Received: (qmail 18298 invoked by uid 22791); 30 Dec 2009 08:06:20 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from yosemite.airs.com (HELO yosemite.airs.com) (64.13.131.148) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 30 Dec 2009 08:06:16 +0000 Received: (qmail 12670 invoked by uid 10); 30 Dec 2009 08:06:14 -0000 Received: (qmail 32404 invoked by uid 500); 30 Dec 2009 08:06:09 -0000 From: Ian Lance Taylor To: Mark Kettenis Cc: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [RFC] frame_id_inner check and -fsplit-stack References: <20091229190720.GE24363@adacore.com> <200912291948.nBTJmbCx011266@glazunov.sibelius.xs4all.nl> Date: Wed, 30 Dec 2009 08:06:00 -0000 In-Reply-To: <200912291948.nBTJmbCx011266@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Tue\, 29 Dec 2009 20\:48\:37 +0100 \(CET\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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 X-SW-Source: 2009-12/txt/msg00430.txt.bz2 Mark Kettenis writes: >> Date: Tue, 29 Dec 2009 23:07:20 +0400 >> From: Joel Brobecker >> >> Ian Taylor just reported on the GDB IRC that the frame_id_inner >> check in get_prev_frame_1 is making debugging difficult when >> the program has been built with -fsplit-stack. This option >> <> just allocated using mmap, so there is no particular ordering>>. >> As a result, if two frames are on different stack segments, >> the ordering of the segments might be such that two valid frames >> might be failing the frame_id_inner check. >> >> Discussing with Ian, he indicated that it should be easy to produce >> a section with magic name. This would allow us to determine that >> the program uses split-stack and that the frame_id_inner may not >> apply. >> >> I can see the following options: >> >> 1. do nothing (ahem); >> 2. remove the check entirely; we currently apply it I think >> when the two frames are normal frames. We already skip it >> when either frame is not normal. >> 3. provide a user setting that allows the user to tell GDB >> that the program uses split stacks; >> 4. skip the test when split stacks is detected. >> >> I don't think we should really consider option (3) if we can indeed >> easily detect split-stack. (1) seems a bit harsh. I am Ok with either >> (2) or (4). It sounds like Ian is willing to make it easy for us to >> detect split-stack, so I'd vote for (4). Given that nearly all the code >> we debug does not use split-stack, we can keep the frame_id_inner check >> a while longer... >> >> Thoughts? > > Ugh, another small step towards completely undebuggable code. Guess > somebody is trying to cram too much bloated overthreaded C++ code into > an onderpowered 32-bit device ;). I actually wrote it for the Go programming language, where programs do tend to be very threaded. > I think we shouldn't add a knob if we don't need to. So I'd say we > defenitely should try (4). My initial idea for implementing this > would be for the unwinder to mark the frames that "split" the stack > (i.e. make the not normal), and skip the check for those frames. I > also think the information should be encoded in the debug information > instead of magic section names that could be lost during (re)linking. Looking at DWARF, I see that there is a calling_convention enum which can be added to the DW_TAG_subprogram for a function. I don't know all that much about DWARF; does that seem like the right sort of thing to do? That wouldn't help with the unwind info, though. There I think we could add a new augmentation code for a split-stack function. The presence of the augmentation would mean that the stack might be out of order when unwinding through this function. I think that would work because unwinders which didn't recognize it would simply ignore it. But again I am far from being an expert in this area. Ian