From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4857 invoked by alias); 23 Oct 2008 12:57:02 -0000 Received: (qmail 4849 invoked by uid 22791); 23 Oct 2008 12:57:02 -0000 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog017.obsmtp.com (HELO eu1sys200aog017.obsmtp.com) (207.126.144.131) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 12:55:56 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Thu, 23 Oct 2008 12:55:51 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id F3D79DA9F; Thu, 23 Oct 2008 12:55:50 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C66F34C116; Thu, 23 Oct 2008 12:55:50 +0000 (GMT) Received: from crx595.cro.st.com (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.8.7a) with ESMTP id CQF15064 (AUTH "denis pilat"); Thu, 23 Oct 2008 14:56:57 +0200 (CEST) Message-ID: <49007456.6090208@st.com> Date: Thu, 23 Oct 2008 12:57:00 -0000 From: Denis PILAT User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Nick Roberts Cc: gdb@sourceware.org Subject: Re: Query user with gdb MI intepreter References: <18688.7480.96669.634046@kahikatea.snap.net.nz> <49004FE5.6020807@st.com> <18688.23242.783095.562854@kahikatea.snap.net.nz> In-Reply-To: <18688.23242.783095.562854@kahikatea.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-10/txt/msg00109.txt.bz2 Nick Roberts wrote: > > If actual behavior is not correct, then I will propose a simple patch > > that is already in place in my version of gdb sources. > > I don't think anyone has considered how MI should behave after an internal > error which really means there is a bug in GDB anyway. There is, but I don't have any patch to submit about it, sorry. dwarf2_restore_rule() is called from execute_cfa_program() with fs->initial.reg set to 0 which leads to a gdb_assert(). That, for sure, comes from a problem we have in our in-house compiler that do not generate right debug information.