From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3543 invoked by alias); 1 Oct 2012 18:39:02 -0000 Received: (qmail 3534 invoked by uid 22791); 1 Oct 2012 18:39:01 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-da0-f41.google.com (HELO mail-da0-f41.google.com) (209.85.210.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Oct 2012 18:38:55 +0000 Received: by dadi14 with SMTP id i14so1717281dad.0 for ; Mon, 01 Oct 2012 11:38:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.136.229 with SMTP id qd5mr43041681pbb.154.1349116734879; Mon, 01 Oct 2012 11:38:54 -0700 (PDT) Received: by 10.68.218.41 with HTTP; Mon, 1 Oct 2012 11:38:54 -0700 (PDT) In-Reply-To: <20121001172618.GA23158@host2.jankratochvil.net> References: <20121001172117.GG30746@adacore.com> <20121001172618.GA23158@host2.jankratochvil.net> Date: Mon, 01 Oct 2012 18:39:00 -0000 Message-ID: Subject: Re: Option to disable frame checking From: Joshua Watt To: Jan Kratochvil Cc: Joel Brobecker , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00014.txt.bz2 >> > Is it acceptable to make a patch that allows this check to be turned >> > off (i.e. "set frame-inner-check off" or similar), or is there another >> > method that is more acceptable? >> >> Knowing that the Go language makes extensive use of alternate stacks, >> I think it's just better to remove the check altogether. > > I do not know about Go alternate stacks but the checks for example already > supports gcc -fsplit-stack. More such features should be rather implemented > than to drop UNWIND_INNER_ID. Could not be GDB taught about thue alternate > stack? I'm not sure how that would be accomplished. AFAIK, there isn't any sort of information in the DWARF debugging format that could be used to (definitively) indicate the thread has jumped stacks, so I think it would have to be determined by something external to the code being debugged. I think that such a heuristic approach could be difficult to get correct in all cases, hence the idea of making it a user configurable option. I won't claim to be an expert in the DWARF debugging format though, so I could be wrong. I also don't know anything about any other debugging formats. -- Joshua Watt