From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13616 invoked by alias); 29 Dec 2009 19:49:31 -0000 Received: (qmail 13606 invoked by uid 22791); 29 Dec 2009 19:49:31 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Dec 2009 19:49:26 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id nBTJmcP5006942; Tue, 29 Dec 2009 20:48:38 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id nBTJmbCx011266; Tue, 29 Dec 2009 20:48:37 +0100 (CET) Date: Tue, 29 Dec 2009 19:49:00 -0000 Message-Id: <200912291948.nBTJmbCx011266@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sourceware.org In-reply-to: <20091229190720.GE24363@adacore.com> (message from Joel Brobecker on Tue, 29 Dec 2009 23:07:20 +0400) Subject: Re: [RFC] frame_id_inner check and -fsplit-stack References: <20091229190720.GE24363@adacore.com> 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/msg00420.txt.bz2 > 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 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.