From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12151 invoked by alias); 4 Oct 2004 16:36:33 -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 12112 invoked from network); 4 Oct 2004 16:36:30 -0000 Received: from unknown (HELO svr68.ehostpros.com) (67.15.48.48) by sourceware.org with SMTP; 4 Oct 2004 16:36:30 -0000 Received: from [61.11.18.135] (helo=pythagoras) by svr68.ehostpros.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42) id 1CEVp4-0002Bb-F2; Mon, 04 Oct 2004 09:36:27 -0700 From: "Amit S. Kale" Organization: LinSysSoft Technologies Pvt Ltd To: Andrew Cagney Subject: Re: kgdb support for gdb Date: Mon, 04 Oct 2004 16:36:00 -0000 User-Agent: KMail/1.5 Cc: gdb-patches@sources.redhat.com References: <200410011314.33157.amitkale@linsyssoft.com> <4161725C.6050009@gnu.org> In-Reply-To: <4161725C.6050009@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410042205.24596.amitkale@linsyssoft.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr68.ehostpros.com X-AntiAbuse: Original Domain - sources.redhat.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - linsyssoft.com X-Source: X-Source-Args: X-Source-Dir: X-SW-Source: 2004-10/txt/msg00057.txt.bz2 On Monday 04 Oct 2004 9:25 pm, Andrew Cagney wrote: > > 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. Thanks a lot for the detailed reply. > 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). I don't suppress any frames. I insert a fake frame so that the fake frame can do the job of reporting correct registers to the previous frame. IT works more or less like inline functions. At present inline functions don't insert fake frames, but I believe it's being worked on. Let me state the problem I am trying to solve. You may be able to provide a better solution to that. schedule() function has a call to macro switch_to. The switch_to macro is an architecture specific macro. It has hand written assembly code that does a part of the context switching job. This code manipulates eip and esp in a non-standard way. Present gdb can't produce backtraces correctly if the frame 0 is inside switch_to. That's obvious since gdb doesn't have dwarf information for those instructions. A few things have been tried to help gdb with this problem. This one is worth mentioning: We report the esp as it would be when switch_to is complete. Since gdb doesn't look into switch_to code, it starts interpretations where switch_to ends. So this works ok for most part. It doesn't solve the problem of all registers, though. The switch_to code has been written intelligently (read over-engineered) to save only those registers which would be expected by gcc to be correct when schedule() function returns. So this task becomes unmanageable and error-prone. > - __sched_text_start > stack.c should definitly not be directly testing that. Instead ... Agreed. I'll make a macro and/or a function switchout. > > - frame attributes > ... the code should start testing for frame attributes: is this a callee > frame; ...... Didn't understand that. > - > 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? Let me try to understand what's involved in this. I'll get back on this later. > - dissassemble > I'm curious, does disassemble work for these context frames? It > currently doesn't for signal trampolines. Will check this too. > - 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. Implementing these in a different way should be straight forward. Could move them into arch dependent files. > - 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. Writing tests should be easy if a kernel is available. Without a kernel, ... I'll think something about this. > > - coding http://www.gnu.org/prep/standards_toc.html > One querk to check is GDB's comment style. Will fix this. -Amit > > 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", " > called>"); } > > + 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