From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 595 invoked by alias); 30 Jan 2006 17:02:48 -0000 Received: (qmail 573 invoked by uid 22791); 30 Jan 2006 17:02:47 -0000 X-Spam-Check-By: sourceware.org Received: from mail.emacinc.com (HELO mail.emacinc.com) (208.248.202.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jan 2006 17:02:44 +0000 Received: from emac77.emacinc.com ([208.248.202.77] helo=eng011.emacinc.com) by mail.emacinc.com with esmtp (Exim 4.50) id 1F3cQB-0002xX-RA; Mon, 30 Jan 2006 11:02:39 -0600 From: NZG To: gdb-patches@sourceware.org Date: Mon, 30 Jan 2006 17:02:00 -0000 User-Agent: KMail/1.8.2 References: <200601231438.26040.ngustavson@emacinc.com> <8f2776cb0601261557x2edce755sd54dbfe12d658267@mail.gmail.com> <200601261803.03994.ngustavson@emacinc.com> In-Reply-To: <200601261803.03994.ngustavson@emacinc.com> Cc: "uClinux development list" MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200601301101.02858.ngustavson@emacinc.com> X-SA-Exim-Connect-IP: 208.248.202.77 X-SA-Exim-Mail-From: ngustavson@emacinc.com Subject: 5282 gdb Eclipse MI support, was remote connection crash Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Relay: X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00472.txt.bz2 > > For reference, I added Dwarf CFI for the _start function in crt0.s for > > the m32c libgloss port: Interesting, but it may be beyond what I have a timeline for at this point. I have had some luck simply by enabling the section of code below, which appears to have been designed specifically for this purpose. Everything appears to be working now, although a little bit slower than I like. Anyway progress is being made. thank you for all your help, Nathan /* If we're inside the entry file, it isn't valid. Don't apply this test to a dummy frame - dummy frame PC's typically land in the entry file. Don't apply this test to the sentinel frame. Sentinel frames should always be allowed to unwind. */ /* NOTE: drow/2002-12-25: should there be a way to disable this check? It assumes a single small entry file, and the way some debug readers (e.g. dbxread) figure out which object is the entry file is somewhat hokey. */ /* NOTE: cagney/2003-01-10: If there is a way of disabling this test then it should probably be moved to before the ->prev_p test, above. */ /* NOTE: vinschen/2003-04-01: Disabled. It turns out that the call to deprecated_inside_entry_file destroys a meaningful backtrace under some conditions. E. g. the backtrace tests in the asm-source testcase are broken for some targets. In this test the functions are all implemented as part of one file and the testcase is not necessarily linked with a start file (depending on the target). What happens is, that the first frame is printed normaly and following frames are treated as being inside the enttry file then. This way, only the #0 frame is printed in the backtrace output. */ /**NZG enabled for expermentation**/ if (1 && this_frame->type != DUMMY_FRAME && this_frame->level >= 0 && deprecated_inside_entry_file (get_frame_pc (this_frame))) { if (frame_debug) { fprintf_unfiltered (gdb_stdlog, "-> "); fprint_frame (gdb_stdlog, NULL); fprintf_unfiltered (gdb_stdlog, " // inside entry file }\n"); } return NULL; } On Thursday 26 January 2006 6:03 pm, NZG wrote: > > For reference, I added Dwarf CFI for the _start function in crt0.s for > > the m32c libgloss port: > > > > http://sourceware.org/cgi-bin/cvsweb.cgi/src/libgloss/m32c/crt0.S?rev=1.2 > >&c ontent-type=text/x-cvsweb-markup&cvsroot=src > > > > You'll need to look at the CFI section of the Dwarf spec to adapt this > > to your processor. (Fortunately, Dwarf CFI is pretty independent of > > the rest of Dwarf, so don't be discouraged by the overall size of the > > spec.) > > Thanks Jim, I'll take a look at her tomorrow. > I'm goin home. > > thx for all you help today, > Gnight.