From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6014 invoked by alias); 4 Oct 2004 15:55:38 -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 5988 invoked from network); 4 Oct 2004 15:55:36 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Oct 2004 15:55:36 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i94FtViD012629 for ; Mon, 4 Oct 2004 11:55:36 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i94FtPr21361; Mon, 4 Oct 2004 11:55:25 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A4F4928D2; Mon, 4 Oct 2004 11:55:08 -0400 (EDT) Message-ID: <4161725C.6050009@gnu.org> Date: Mon, 04 Oct 2004 15:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: "Amit S. Kale" Cc: gdb-patches@sources.redhat.com Subject: Re: kgdb support for gdb References: <200410011314.33157.amitkale@linsyssoft.com> In-Reply-To: <200410011314.33157.amitkale@linsyssoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00052.txt.bz2 > Index: src/gdb/stack.c > =================================================================== > --- src.orig/gdb/stack.c 2004-08-03 06:27:26.000000000 +0530 > +++ src/gdb/stack.c 2004-10-01 12:59:38.000000000 +0530 > @@ -45,6 +45,7 @@ > #include "dictionary.h" > #include "reggroups.h" > #include "regcache.h" > +#include "objfiles.h" See Mark's general comments - I agree, the support should be there on all GNU/Linux systems, and not require special customization. As for details of the lk files, I'll leave that to GNU/Linux patch revierws. However, for the frame stuff, I've noticed the below. Yes it's long. But mostly mechanical: - "gdb doesn't lie" This means that if the stack contains a context frame then the context frame is included in the backtrace. Adding a feature to supresses certain frames in a back-trace would be interesting but, I think, should be added separatly (and needs to be user configurable). - __sched_text_start stack.c should definitly not be directly testing that. Instead ... - frame attributes ... the code should start testing for frame attributes: is this a callee frame; ...... - A things-to-do-today task is modify the stack/frame/... code so that it displays something like: stopped at +0x23 (i.e, the offset into the signal trampoline is displayed - at present it isn't) are you interested in trying to [separatly] fix this? - dissassemble I'm curious, does disassemble work for these context frames? It currently doesn't for signal trampolines. - PC_REGNUM and SP_REGNUM I noticed code refering to these - they are definitly on their way out - you'll need to find another way of implementing that. I'm also wondering about the lm-tdep code that computes the frame ID, the code addr should be the start of that code block and not the current PC - a frame ID's code and stack addresses are both constant through out the lifetime of a frame. - testing As with signal trampolines, we'll need to ensure that this is tested. It should be possible to construct testsuite additions that show GDB backtracing at least through one of these frames (Past experience has taught us that untested code unfortunatly and consistently bitrots). I think it's possible to construct something without requiring a kernel. - coding http://www.gnu.org/prep/standards_toc.html One querk to check is GDB's comment style. I think we can wack these out relatively quickly. Andrew > /* Prototypes for exported functions. */ > > @@ -420,9 +421,14 @@ > struct symtab_and_line sal; > int source_print; > int location_print; > + CORE_ADDR pc; > + struct frame_id fid; > + struct minimal_symbol *schedbegin; > + struct minimal_symbol *schedend; > > if (get_frame_type (fi) == DUMMY_FRAME > - || get_frame_type (fi) == SIGTRAMP_FRAME) > + || get_frame_type (fi) == SIGTRAMP_FRAME > + || (get_frame_type (fi) == CONTEXT_FRAME && print_level != 0)) > { > struct cleanup *uiout_cleanup > = make_cleanup_ui_out_tuple_begin_end (uiout, "frame"); > @@ -455,12 +461,38 @@ > annotate_signal_handler_caller (); > ui_out_field_string (uiout, "func", ""); > } > + else if (get_frame_type (fi) == CONTEXT_FRAME) > + { > + annotate_context_entry (); > + ui_out_field_string (uiout, "func", ""); > + } > ui_out_text (uiout, "\n"); > annotate_frame_end (); > > do_cleanups (uiout_cleanup); > return; > } > + /* Don't print context switch and scheduler frames if we are at level 0. */ > + if (get_frame_type (fi) == CONTEXT_FRAME) > + { > + schedbegin = lookup_minimal_symbol("__sched_text_start", NULL, > + symfile_objfile); > + schedend = lookup_minimal_symbol("__sched_text_end", NULL, > + symfile_objfile); > + if (schedbegin && schedend) > + while ((fi = get_prev_frame(fi)) != NULL) > + { > + fid = get_frame_id(fi); > + pc = 0; > + if (!fid.code_addr_p) > + break; > + pc = get_frame_id(fi).code_addr; > + if (SYMBOL_VALUE_ADDRESS(schedbegin) >= pc) > + break; > + if (SYMBOL_VALUE_ADDRESS(schedend) <= pc) > + break; > + } > + } > > /* If fi is not the innermost frame, that normally means that fi->pc > points to *after* the call instruction, and we want to get the