From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19598 invoked by alias); 4 Apr 2002 20:15:29 -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 19584 invoked from network); 4 Apr 2002 20:15:26 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 4 Apr 2002 20:15:26 -0000 Received: from localhost.redhat.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA23707; Thu, 4 Apr 2002 12:13:30 -0800 (PST) Received: by localhost.redhat.com (Postfix, from userid 469) id 4BFB011406; Thu, 4 Apr 2002 15:09:28 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15532.45816.153296.172640@localhost.redhat.com> Date: Thu, 04 Apr 2002 12:15:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , Michael Elizabeth Chastain , Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [RFA] import drow dbxread.c fix to branch In-Reply-To: <20020404144007.A10769@nevyn.them.org> References: <200204040536.g345a6t30923@duracef.shout.net> <20020404010112.A13460@nevyn.them.org> <15532.43273.686279.120593@localhost.redhat.com> <20020404144007.A10769@nevyn.them.org> X-SW-Source: 2002-04/txt/msg00118.txt.bz2 Daniel Jacobowitz writes: > > > > Take a look at the way gdbtk does it, in > > gdbtk/generic/gdbtk-cmd.c:gdb_disassemble_driver(). > > Can we adopt that solution? > > > > (I really can't wait until we can get rid of this duplication/triplication of > > disassembly code. I think I'll start cleaning some things up). > > I'm not sure. That code assumes a different meaning of line==0 than > the one we're using. Particularly, if I understand correctly, the > meaning in gdbtk comes from a set of Cygnus-internal stabs for handling > live range splitting, which never made it into any public GCC and are > completely obsoleted by DWARF-2. I prefer: > Yes, you are right, that code predates even gdbtk bein contributed publically. I initially thought that it was a recent fix. > > + /* Skip any end-of-function markers. */ > > + if (le[i].line == 0) > > + continue; > > + > > > to: > > /* GCC sometimes emits line directives with a linenumber > of 0. It does this to handle live range splitting. > This may be a bug, but we need to be able to handle it. > For now, use the previous instructions line number. > Since this is a bit of a hack anyway, we will just lose > if the bogus sline is the first line of the range. For > functions, I have never seen this to be the case. */ > > if (le[i].line != 0) > { > mle[newlines].line = le[i].line; > } > else > { > if (newlines > 0) > mle[newlines].line = mle[newlines - 1].line; > } > > > i.e. skip the line, not fake up a line number for it. It's a > special-purpose marker, not a generic line number. > > If you agree with me, want me to update gdbtk's version to match? Does > this same code exist in a third location? > I guess posting a patch to the insight list can do no harm. It's up to them to approve it. There is no real third location, but rather a third way to do disassembly in gdb proper (disassemble_cmd). Anyway, the code can go in for the MI part. Elena > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer