From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20683 invoked by alias); 26 Jul 2003 01:26:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20676 invoked from network); 26 Jul 2003 01:26:29 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 26 Jul 2003 01:26:29 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 429272B7F; Fri, 25 Jul 2003 21:26:23 -0400 (EDT) Message-ID: <3F21D8BE.8050401@redhat.com> Date: Sat, 26 Jul 2003 01:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, amichelotti@ipitec.it, Michael Snyder Subject: Re: patch for info threads problem with target arm-elf (PR 1199). References: <3F200D12.6000103@ipitec.it> <3F21CAA4.30400@redhat.com> <20030726002921.GA5573@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00458.txt.bz2 > On Fri, Jul 25, 2003 at 05:26:12PM -0700, Michael Snyder wrote: > >> Andrea Michelotti wrote: >> > >> >----------------------- >> >Andrea Michelotti >> >HW/SW Co-Design Manager >> >IPITEC (ATMEL) > >> >> >> I think it can be approved. Do you have an FSF copyright assignment? > > > I'd want to ping Andrew about this first before scattering NULL pointer > checks - Andrew, does "there is always a frame" include when the > inferior does not exist yet? Kind of :-) If the inferior doesn't exist, GDB should never get to find out the answer. See get_current_frame and all those error() checks. > Also, I think a better solution to this actual crash is for info > threads to bail out early if we don't have an inferior. Probably > target_has_registers (). Yes, looking at the start of info_threads_command: > static void > info_threads_command (char *arg, int from_tty) > { > struct thread_info *tp; > ptid_t current_ptid; > struct frame_info *cur_frame; > int saved_frame_level = frame_relative_level (deprecated_selected_frame); > int counter; > char *extra_info; > > /* Avoid coredumps which would happen if we tried to access a NULL > deprecated_selected_frame. */ > if (!target_has_stack) > error ("No stack."); The references to: deprecated_selected_frame should have set off alarm bells! A quick fix would be to call get_selected_frame() (and delete that error check). The correct fix involves per-thread frames ... Andrew